Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Embedded Mozilla, Cookies
| Embedded Mozilla, Cookies [message #526034] |
Thu, 08 April 2010 14:53  |
 Markward Schubert
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi everyone.
I have a question concerning Cookie-Management with an embedded Mozilla.
I don't think this is a bug, but rather a really difficult scenario. Any suggestions on tricks and workarounds are very much apprechiated.
The problem:
We have a RCP application communicating with it's backend via http-based spring webservices.
At the center of the communication of these services on the client side, is an instance of apache common's httpclient.
We also display some content, served by our server using an embedded Mozilla. Parts of the content, especially some images can only be accessed with a valid session. To implement sessionhandling on the serverside we use Spring security if this is of any interest.
Our strategy was now to let the embedded Mozilla participate in the httpclient's session by setting it with Browser.setCookie(). This solution turned out as more problematic than we thought. In fact setting the cookie worked at first, but turned out problematic as we gave the cookies an endless expiry time. During the operation of the application we subsequently call Browser.setCookie() to ensure, that the very current session is exposed to Mozilla. This resulted in the "same" cookie piling up in Mozilla's cookies.sqlite. This seems to be specification conform behaviour for cookies with endless lifetime.
When the client is opened a second time, it seems, that sometimes some "older" cookies are chosen, even if a more recent session cookie has been set wit Browser.setCookie(), causing problems, when the session expired on the serverside, basically meaning, that the resource does not show.
Letting the cookie expire earlier is not an option, as the browser is used as an editor, based on tinymce. So in general a user could stay in the editor longer, than the session lives and then insert some html-template-snippet, which needs to load session-protected content from the server, resulting in an authentication challenge.
With the webservices this is not a problem, as we intercept the authentication challenge with the commons http-client, but in the situation described, mozilla would be the first to "notice", that the session expired.
Ideally we would like to discard the cookie when the client app closes.
|
|
| |
| Re: Embedded Mozilla, Cookies [message #526776 is a reply to message #526215] |
Mon, 12 April 2010 20:46  |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
Hi,
Does a line like the following have any better success at clearing the
cookie?
String invalidateCookie = "JSESSIONID=" + ((RemoteServiceFactory)
factory).getSessionId() + "; expires=Thu, 01-Jan-1970 00:00:01 GMT";
Also, to confirm, the cookie set/attempted-clear is always on the exact same
url string (the "url" argument to Browser.setCookie()), right?
Lastly, is the setting/attempted-clearing happening before any
SWT.MOZILLA-style Browsers have been instantiated? If so, then as an
experiment can you try creating a Browser with this style before touching
the cookies? I suggest this just because there was a bug with this scenario
that was fixed in the eclipse 3.6 stream (I don't think there was an
associated bug report).
HTH,
Grant
"Markward Schubert" <markward.schubert@gmail.com> wrote in message
news:hpmrlc$rnq$1@build.eclipse.org...
> Maybe I should add some information:
>
> My recent approach was to invalidate the cookie which was set before and
then immediately set it to a new value:
>
>
>
>
> String invalidateCookie = "JSESSIONID=" + ((RemoteServiceFactory)
factory).getSessionId() + ";Max-Age=0;";
> String cookieValue = "JSESSIONID=" + ((RemoteServiceFactory)
factory).getSessionId() + ";Max-Age=2100;";
>
> boolean success = Browser.setCookie(invalidateCookie,cookieURL);
>
> if(success) {
> log.debug("Cookie successfully set to be discarded);
> } else {
> log.debug("Setting Cookie to be discarded failed);
> }
>
> success = Browser.setCookie(cookieValue,cookieURL);
>
> if(success) {
> log.debug("Cookie successfully set to: value="+cookieValue+"
url="+cookieURL);
> } else {
> log.debug("Cookie failed: value="+cookieValue+" url="+cookieURL);
> }
>
>
>
> Unfortunately with this approach the problem persists. When I log in a
second or third time, old sessions are used from time to time, leading to
errors. Also the cookies stay in the sqlite-db of mozilla.
|
|
|
| Re: Embedded Mozilla, Cookies [message #526854 is a reply to message #526776] |
Tue, 13 April 2010 10:02 |
Markward Schubert
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi!
Thanks for the reply!
I tried all the suggestions, but had no success. May be I can provide some more information.
As a xul-runner we use FirefoxPortable 3.2.3.
SWT-version is: 3.6.0.v3631
After checking the file cookies.sqlite in the application-data folder of Mozilla, cookies still persist, all with an expiry date of 2030. Well I actually don't know the exact purpose of this database, meaning if it is expected behaviour to keep the cookies in there, even if they are invalidated, but as all of them have the same expirydate far in the future, to me it seems like simply the mechanism of invalidating cookies does not work.
Also for me the question remais, if this should work at all. I mean, does the Browser-API offer an interface to the whole logic of cookie-management, or is it just some kind of shortcut to a "put this cookie into the cookie-store regardless of anything"-method?
Currently we think of going towards basic authentication, which will presumably work. But working with session would a far more elegant solution to our situation, so if you have any further ideas, they will be very much appreciated.
Thanks for the help!
Markward
|
|
|
| Re: Embedded Mozilla, Cookies [message #526955 is a reply to message #526854] |
Tue, 13 April 2010 14:48 |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
The Browser calls mozilla's cookie-related api, so cookies should be managed
properly. I've never tried FirefoxPortable before, but it presumably should
not be different from other mozilla-based apps like xulrunner, which is
what's typically embedded.
The snippet below demonstrates setting and clearing of a persistent cookie,
and it works for me. Does it work for you? And if so, are you able to
change it to more closely resemble your case, to show clearing of persistent
cookies failing?
public static void main(String[] args) {
Device.DEBUG = true;
//
System.setProperty("org.eclipse.swt.browser.XULRunnerPath", "e:\\xulrunner-1.
9.2\\xulrunner"); // set if needed
final String url = "http://www.eclipse.org";
final String cookieName = "Test";
Display display = new Display();
Shell shell = new Shell(display);
shell.setBounds(10,10,600,600);
shell.setLayout(new GridLayout());
Browser browser = new Browser(shell, SWT.MOZILLA);
// browser.setUrl(url); // not really needed
Button add = new Button(shell, SWT.PUSH);
add.setText("Add Cookie");
add.addListener(SWT.Selection, new Listener() {
public void handleEvent(Event event) {
System.out.println("add success: " +
Browser.setCookie(cookieName + "=swt; expires=Thu, 01-Jan-2030 00:00:01
GMT", url));
}
});
Button get = new Button(shell, SWT.PUSH);
get.setText("Get Cookie");
get.addListener(SWT.Selection, new Listener() {
public void handleEvent(Event event) {
System.out.println("Get " + cookieName + ": " +
Browser.getCookie(cookieName, url));
}
});
Button clear = new Button(shell, SWT.PUSH);
clear.setText("Clear Cookie");
clear.addListener(SWT.Selection, new Listener() {
public void handleEvent(Event event) {
System.out.println("clear success: " +
Browser.setCookie(cookieName + "=swt; expires=Thu, 01-Jan-1970 00:00:01
GMT", url));
}
});
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
display.dispose();
}
Grant
"Markward Schubert" <markward.schubert@gmail.com> wrote in message
news:hq1ff8$hnh$1@build.eclipse.org...
> Hi!
>
> Thanks for the reply!
>
> I tried all the suggestions, but had no success. May be I can provide some
more information.
>
> As a xul-runner we use FirefoxPortable 3.2.3.
> SWT-version is: 3.6.0.v3631
>
> After checking the file cookies.sqlite in the application-data folder of
Mozilla, cookies still persist, all with an expiry date of 2030. Well I
actually don't know the exact purpose of this database, meaning if it is
expected behaviour to keep the cookies in there, even if they are
invalidated, but as all of them have the same expirydate far in the future,
to me it seems like simply the mechanism of invalidating cookies does not
work.
>
> Also for me the question remais, if this should work at all. I mean, does
the Browser-API offer an interface to the whole logic of cookie-management,
or is it just some kind of shortcut to a "put this cookie into the
cookie-store regardless of anything"-method?
>
> Currently we think of going towards basic authentication, which will
presumably work. But working with session would a far more elegant solution
to our situation, so if you have any further ideas, they will be very much
appreciated.
>
> Thanks for the help!
> Markward
|
|
|
| Re: Embedded Mozilla, Cookies [message #526975 is a reply to message #526955] |
Tue, 13 April 2010 15:44 |
Markward Schubert
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Hi Grant, thanks for the snippet!
I tried it emediately with some interesting results.
I started the application and opened the cookies.sqlite in an SQLite Browser in parallel.
It seems, that the database is used to persist cookies when the browser instance is closed. The following scenarios I could reproduce:
scenario I
+ start the app
+ add the cookie
+ read the cookie -> cookie read
+ clear the cookie
+ read the cookie -> cookie == null
+ close app
+ query for the cookie in db -> no cookies in db
scenario II
+ start the app
+ add the cookie
+ read the cookie -> cookie read
+ close app
+ query for the cookie in db -> 1 cookie in db
scenario III (after scenario II with one cookie in the db)
+ start the app
+ read the cookie -> cookie read
+ add the cookie
+ read the cookie -> cookie read
+ close app
+ query for the cookie in db -> 2 cookies in db
scenario IV (after scenario III with 2 cookies in the db)
+ start the app
+ read the cookie -> cookie read
+ clear the cookie
+ read the cookie -> cookie read
+ clear the cookie
+ read the cookie -> cookie == null
+ close app
+ query for the cookie in db -> 2 cookies in db
This leads me to the following conclusion:
The db is the persistent store between two browser runs. Cookies, which are not invalidated during a browser-session will be persisted to the db. When a browser-session starts, persisted cookies from the db are read to the current "in-memory-session". They can be invalidated one after the other, until none are left, but this only applies in memory. When the app closes, the cookies stay in the db and are available to the next browser session automatically.
So a solution to our problem would be to make sure, no valid cookies are left in memory before the last browser was closed, but this seems to be veriy fragile. As soon as a cookie survives an is beeing persisted, this will reoccur every subsequent start.
I don't know how much you are involved in the Mozilla engine, would you say the described behaviour with invalidated cookies from former session staying in the db, is correct?
|
|
|
| Re: Embedded Mozilla, Cookies [message #527002 is a reply to message #526975] |
Tue, 13 April 2010 16:12 |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
Hi,
I've stumbled on something unexpected which may be helpful. My previous
snippet included a "//browser.setUrl... // not really needed" line. If this
line is uncommented and a navigate to some url occurs before
adding/clearing/reading the cookies (the navigate can be to any url) then I
see the persistent cookie being successfully removed from the cookies
database. Can you try this on your end, just uncomment this line in the
snippet?
Grant
"Markward Schubert" <markward.schubert@gmail.com> wrote in message
news:hq23hl$udn$1@build.eclipse.org...
> Hi Grant, thanks for the snippet!
>
> I tried it emediately with some interesting results.
>
> I started the application and opened the cookies.sqlite in an SQLite
Browser in parallel.
>
> It seems, that the database is used to persist cookies when the browser
instance is closed. The following scenarios I could reproduce:
>
> scenario I
>
> + start the app
> + add the cookie
> + read the cookie -> cookie read
> + clear the cookie
> + read the cookie -> cookie == null
> + close app
> + query for the cookie in db -> no cookies in db
>
> scenario II
>
> + start the app
> + add the cookie
> + read the cookie -> cookie read
> + close app
> + query for the cookie in db -> 1 cookie in db
>
> scenario III (after scenario II with one cookie in the db)
>
> + start the app
> + read the cookie -> cookie read
> + add the cookie
> + read the cookie -> cookie read
> + close app
> + query for the cookie in db -> 2 cookies in db
>
> scenario IV (after scenario III with 2 cookies in the db)
>
> + start the app
> + read the cookie -> cookie read
> + clear the cookie
> + read the cookie -> cookie read
> + clear the cookie
> + read the cookie -> cookie == null
> + close app
> + query for the cookie in db -> 2 cookies in db
>
> This leads me to the following conclusion:
>
> The db is the persistent store between two browser runs. Cookies, which
are not invalidated during a browser-session will be persisted to the db.
When a browser-session starts, persisted cookies from the db are read to the
current "in-memory-session". They can be invalidated one after the other,
until none are left, but this only applies in memory. When the app closes,
the cookies stay in the db and are available to the next browser session
automatically.
>
> So a solution to our problem would be to make sure, no valid cookies are
left in memory before the last browser was closed, but this seems to be
veriy fragile. As soon as a cookie survives an is beeing persisted, this
will reoccur every subsequent start.
>
> I don't know how much you are involved in the Mozilla engine, would you
say the described behaviour with invalidated cookies from former session
staying in the db, is correct?
>
>
>
>
>
>
>
>
>
>
>
>
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 14:24:44 GMT 2024
Powered by FUDForum. Page generated in 0.02987 seconds |
] 
Search
Help
Register
Login
Home
