SyncProxy has some issue when the server side is checking cookie and sessionid

[F4bwDP6a6W]

Hi,

In our company has product using GWT, and I want to build a Java client for it.
I searched whole network, and find SyncProxy is fit my needs.

But I find some issue with it. If the site is required login(cookieManager). the setBaseURL function doesn't pass the cookie in. So that in the populatePolicyMap function, there are "getResposeText", this is establishing a http connection to server, so if there's no cookie information, the server will always return login page, so we cannot get the wanted files(JS, gwt.rpc etc).

I want to contribute and enhance this feature, is that ok?

                CookieManager cookiemanager = LoginUtils.loginFormBasedJ2EE(baseURL, "username", "password");

                SyncProxy.setBaseURL(baseURL,cookiemanager);

                StandardDispatchService rpcService =  SyncProxy.createProxy(StandardDispatchService.class,
                        new ProxySettings().setCookieManager(cookiemanager));

[jcricket]

Jerry,

Thank you, you're absolutely welcome to enhance this feature. I appreciate the assistance. A couple of notes to be aware of: The J2EE for based login method #LoginFormBasedJ2EE that you mentioned uses an outdated authentication system known as ClientLogin. This method was deprecated by Google about 3 years ago and is actually going to be shut down in about 3 weeks (https://developers.google.com/accounts/docs/AuthForInstalledApps). For that reason, I did not enhance the J2EE login system with the 0.5 update (I apologize for not making that clear in the documentation). For App Engine hosting, this may affect your login abilities out-right, though I haven't found much documentation to confirm what the results will be for attempting to use ClientLogin after April 20.

I am working on resolving this issue by updating the code base to utilize OAuth 2.0 as is recommended Issue 45. I have a working solution implemented within the GSP Android library (see the gae-auth branch), which I'm currently working on cleaning up. I'm planning to enhance the Java Login features that you are using in much the same way. The tricky part is that both enhancements require some upgrades to the servlets (Keep an eye on this wiki for examples: https://github.com/jcricket/gwt-syncproxy/wiki/OAuth-2.0-App-Engine-Authentication. Please be aware this wiki is a work in progress). If you, are working this feature, I recommend you look at doing so using OAuth 2.0 (https://developers.google.com/accounts/docs/OAuth2) so that your work is not wasted on a deprecated system.

If not, as I said I am working on upgrading the system with OAuth 2.0 credentials, but based on other current work, I don't have a projected release date for these updates (though I am hoping to get it out by the end of April since I am expecting the ClientLogin deprecation to cause significant problems for users). Using the CookieManager may be supported in a down-the-road update to store encrypted session values and the like, but for the current solution, the OAuth 2.0 tokens and such are not utilizing cookies for security reasons (client-side attacks).

[F4bwDP6a6W]

Hi Preethum,
Yes, I totally understand your concern.
LoginFormBasedJ2EE was deprecated by google, but I think login form based authentication is still being used by some of the systems over world. Such as our system, not so fashion but still commercial used by customers. And the server side cannot be changed, as it's not maintained by me or my close colleagues, we just want to have a java client to call remote functions on server side.

I know it's less secure, but in recent months/ year it will not be improved, at least in this system.
So I am glad to enhance that feature, I will create a new function, and try not to impact the existing logic.

[jcricket]

Sounds great, thanks. If you are able to find some links or documentation verifying how this system will work after Google's shutdown period, let me know and I'll add that to the Wiki for other users still using the system as you are to have a reference point. Once you've got it working with some testing, send a PR and I'll look into integrating it into the main branch with the next release.