On 18 jan 2010, at 23:09, Johan Henselmans wrote:
> I have a site that has part of its content on one website with its own
> unique DNS-addres, and the Webobjects app resides in an iFrame on another
> website with another DNS-address.
>
> The first call from the website fills the frame with a directAction, then the
> webObjects app in the iFrame is on its own: no funky inter-frame-inter-domain
> javascript messaging whatsoever.
>
> That works fine with Firefox, Opera, Chrome, Safari, and Chimera on different
> platforms. However somebody told me of an obscure webbrowser called something
> like InTheNet Exploder or what, and guess what? That thing does not work with
> this setup.
>
> I first thought that it might have something to do with cross-site scripting,
> so I turned that security setting off that prevented that from working. That
> did not help. The odd thing was that the moment the application in the iFrame
> is continued in a new tab (just right click on a link in the app and go to
> new tab), the thing worked perfectly.
>
> On a hunch, I looked for the cookies setting in this IE thingy as I had set
> the sessionid stored in cookies with setStoresIDsInCookies(true) in the
> Session constructor.
> You can find these thing under the Advanced Privacy Setting.
>
> There was a checkbox to always allow session cookies.
>
> When I turned that thing on so it always allowed for Session Cookies, it was
> fixed.
>
> After removing the setStoresIDsInCookies(true) and restoring the default
> setStoresIDsInCookies(true), everything even worked in the default settings
> of this Explorer thing.
>
Oops; meant to mention setStoresIDsInURLs(true) and
setStoresIDsInCookies(false) as the default option.
Which lead me to the following experience:
Anybody aware of any side effects of setting
setStoresIDsInURLs(true);
setStoresIDsInCookies(true);
in the session constructor?
I tried it, and it did seem to work in Internet Explorer, Firefox and Safari.
The reason is that I do not want to burden the compliant browsers with not
being able to traverse the surrounding environment of the iframe the
reservation app is framed in, and coming back to continue the reservation only
to discover that their session has gone and they have to start all over again.
So ABIE (Anything But Internet Explorer) will use the cookies sessionids, and
Internet Explorer will use the URL sessionids.
And I do not want to bother about checking for Browsers, as I would have to do
it at every Direct Action entrance into the app that would lead to a session:
if(request().headerForKey("User-Agent").contains("MSIE")){
mySess().setStoresIDsInCookies(false);
mySess().setStoresIDsInURLs(true);
log.info("NOOO: Internet Explorer");
} else {
mySess().setStoresIDsInCookies(true);
mySess().setStoresIDsInURLs(false);
log.info("Anything goes but Exploder");
}
Unless somebody knows a more elegant solution with three lines of code in one
central place that would take care of the sessionid probs with Internet Explorer
> Just to make sure that nobody else has to fire up WireShark, remove all his
> website code to barebones, test on different websites to discover it seems to
> have something to do with cross-site scripting and waste another day that
> should have been spent in blissful ignorance.
>
> Johan Henselmans
> jo...@netsense.nl
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/johan%40netsense.nl
>
> This email sent to jo...@netsense.nl
Johan Henselmans
jo...@netsense.nl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
