Sharing Cookies between BrowserComponent and ConnectionRequest

61 views
Skip to first unread message

nickk...@gmail.com

unread,
Jun 15, 2017, 1:02:33 AM6/15/17
to CodenameOne Discussions
I've spent days working with a helpful tester and there seems to be a problem in persisting Cookies between the BrowserComponent and ConnectIonRequest. The use case is pretty simple. Sorry about all the details, I'm desperate for a solution as soon as possible and don't want to go back and forth covering things we've already tried.

I have a web application that is wrapped in Codename One. This actually helps testing as we can test performance in the device browser compared to in the Codename One app easily.

The app shows a BrowserComponent with the web app in it and can log in. After logging in they can access the web app fine.

In order to register correctly for notifications the app needs to obtain a token from the server, this is down after logging in (using the BrowserNavigation callback to check when we've successfully logged in) and then makes a ConnectionRequest to a specific URL on the server in order to get a token.

This ConnectionRequest is authenticated with the same cookie / session as the webbrowser and works correctly. However after making this connection request the BrowserComponent is no longer logged in (cookie no longer set) and the next action you take in the app kicks you out to the log in page.

1. BrowserComponent shows log in page
2. On succesful log in the BrowserComponent is redirected to a known URL
3. When the BrowserNavigationCallback detects this logged in URL it initiates a ConnectionRequest to an API endpoint on the same server
4. The API endpoint responds as expected with the user logged in.
5. The BrowserComponent no longer registers the user as logged in and the server kicks them back to the log in page.

Skip steps 3 & 4 and the user stays logged in forever. Simulate these steps in a desktop or mobile browser and the user stays logged in all the time.

I realise that there are a lot of moving pieces and unknowns here for anyone trying to help but I believe they can be ignored because if we use the device's browser we can log in, we can also hit the URL that the connection request hits, get the required result and remain logged in to the web app. On the device if we don't make the ConnectionRequest we stay logged in.

We have seen this on the Simulator and Android and iOS however on the simulator it is erratic, sometimes it'll be immediately logged out other times it'll stay logged in for 10 minutes or so. On Android it is immediate, after the ConnectionRequest 'uses' the cookie its no longer set for the BrowserComponent. iOS also logs out, we haven't found a clear pattern for this. If I don't make the ConnectionRequest on all platforms the BrowserComponent will stay logged in, even between runs of the app which is the desired behaviour. The cookie has a six month expiry and without making the ConnectionRequest it stays logged in between runs of the app as it should.

I'm using:

    ConnectionRequest.setUseNativeCookieStore(true);

I've tried with
ConnectionRequest.setUseNativeCookieStore(false);

and get the same result.

Any help very much appreciated, I don't know if this is a CN1 bug or a misuse but I thoroughly tested a very similar set up at the end of last year and it stayed logged in all the time.




Shai Almog

unread,
Jun 16, 2017, 2:22:40 AM6/16/17
to CodenameOne Discussions
I didn't deal much with the native store cookies feature maybe Steve has an idea.
Have you tried setting the headers manually?

nickk...@gmail.com

unread,
Jun 18, 2017, 6:15:00 PM6/18/17
to CodenameOne Discussions
I haven't tried that, how can I get the cookie from the BrowserComponent in order to set it on the ConnectionRequest header?

Shai Almog

unread,
Jun 19, 2017, 12:46:54 AM6/19/17
to CodenameOne Discussions
I thought that part was already working for you? Getting it once?
Maybe you can get it in the JavaScript side?

nickk...@gmail.com

unread,
Jun 19, 2017, 5:09:14 PM6/19/17
to CodenameOne Discussions
After logging in via BrowserComponent the next ConnectionRequest automagically has the right cookies set but after that the BrowserComponent seems to lose them so is then logged out. I'm not explicitly setting cookies anywhere.

If I don't make a ConnectionRequest then the cookies in the BrowserComponent stay set and the user stays logged in. 

Shai Almog

unread,
Jun 20, 2017, 12:25:48 AM6/20/17
to CodenameOne Discussions
I'm guessing this is because of the native store sync overriding the cookies but Steve knows more about this. Unfortunately he's up to his neck in some tasks for the 3.7 release.
You get the cookies in the first request. Can't you send them back thru the JS bridge?

nickk...@gmail.com

unread,
Jun 22, 2017, 8:54:06 PM6/22/17
to CodenameOne Discussions
I ended up using BrowserComponent.executeAndReturnString and used a synchronous javascript call to make the same call that the ConnectionRequest was doing. Its a bit of a hack, requires a synchronous call and injects logic in javascript in the middle of the app but it does get the response from the end point and doesn't log out the browser component while doing it.

As a result its working which is fine for now, but I think it does highlight an issue with the way cookies are shared between BrowserComponent and ConnectionRequest, the following process appears to be problematic:

1. Log in via a BrowserComponent -> sets cookie
2. Make a ConnectionRequest to the same domain -> uses cookie fine
3. Further action on BrowserComponent -> cookie is gone

By replacing step 2 with a javascript call to the same endpoint within the existing BrowserComponent it stays online.

Cheers,

Shai Almog

unread,
Jun 23, 2017, 2:19:53 AM6/23/17
to CodenameOne Discussions
I think it's best to file an issue with the description and if possible a test case. Steve is probably more qualified to handle that and I can just assign it to him. There is a deep pipeline of issues so it's hard to see when he'll get to it but once it's in the issue tracker there is more of a chance it will be reached.
Reply all
Reply to author
Forward
0 new messages