Frames Anomalies

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2013-02-05 23:37]:
> > My application occupies a browser window with multiple frames.  I submit a
> > form from one of the frames and expect the returned output to occupy the
> > same frame.  My session has timed out, and the re-authentication login page
> > occupies the entire browser window.
> 
> That would not be typical, but if it did happen, that would be a
> consequence of your application and configuration, not
> Shibboleth. The IdP will not generally work in a frame, so it isn't
> clear what your goal is, but if the whole window replaces, then the
> request to the server was *not* just within the frame, but for the
> frameset. That in turn was apparently protected, and required a new
> login, and so the whole window changed.

Maybe the IDP has some "break out of frames" Javascript code enabled.
As frames hide the actual location of the IdP it is generally very
much not welcome to frame an IdP login page since the subject has no
way of knowing where the data is being sent to (other than viewing the
source markup of the relevant frame).
(We use the X-FRAME-OPTIONS response header with "DENY" value, so with
our IdP you'd be stuck an empty frame, IIRC.)

> > (4) Is the original HTML attribute "target" passed (retained) through the
> > entire re-authentication process?
> 
> That is a client-side attribute, it has no effect on the web
> requests the server sees. There's nothing to preserve. The browser
> has decided in what frame to perform requests, it's not up to the
> server and is not reflected in any URLs.

One could set SSO/@relayState to always point at the start frame?
-peter