Community
Participate
Working Groups
Created attachment 203545 [details] Eclipse project with webapp and SWT app demonstrating the problem If the SWT Browser loads a page from domain A, say a.com, which contains an iframe that loads content from domain B, say b.com. The responses/redirects from b.com sets one or more cookies, but the following requests from the iframe - still to b.com within the path of the cookies - do include the cookies! Is there a particularly restrictive version of the "same origin policy" in play here? This works in other browsers. When a login is timed out (or has never taken place) in an AJAX request, our webapp detects this, and requests a protected resource from an iframe, gets redirected to an IdP which normally initiates a session (with a cookie) and shows a login prompt. But in my case this fails badly because the browser does not correctly take the given cookies in the iframe. I attach a minimal example, with a webproject containing an index.html with an iframe that loads bing.com, which tries to set a number of cookies. After the projects is started in a server, and the URL in Main.java is set to your local URL of the testproject, set up a web debugging proxy and run Main.java which uses the SWT Browser component to show the page. This should show you that bing.com tries to set a number of cookie, but the subsequent requests to bing.com from the iframe do not include the cookies!
In the second sentence I should of course have written that "...the following requests from the iframe - still to b.com within the path of the cookies - do NOT include the cookies!"
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
