0

Well, I have a tricky question, but hopefully someone can point me to a simple enough direction as Google was not really helpful...

I have the following architecture:

  1. Server-side: Java Spring MVC server with Tomcat container - FORM authentication (via j_security_check) vs a custom DataSourceRealm, which after successful authentication injects the GenericPrincipal with additional session-specific data (custom Principal class)
  2. Client-side: Ionic hybrid app with AngularJS 1.5 running in Chrome and on Android 5.0 device

(note: there is a different web-app working with the same server, as well, and operating correctly)

The app runs fine when emulated in Chrome with --disable-web-security, but when it runs on the device itself it fails with very peculiar symptoms:

  1. j_security_check logs the user correctly and generates a complete and correct Principal object at the end of the authenticate method
  2. Subsequent requests to the server are routed to the correct Spring controllers, but when inspecting the request object - the Principal object and the the authType parameter of the request are both null (contrasted by the correct values of an instance of GenericPrincipal and "FORM", respectively - when requested from browser or the web-app).

Additional info (searched around for a bit...):

  1. withCredentials=true is set in AngularJS config
  2. CORS filter is set to the Tomcat provided filter (with permissive settings) and origin is set to * in client config: <access origin="*"/>
  3. CSP is set to the permissive settings: <meta http-equiv="Content-Security-Policy" content="default-src * 'unsafe-inline' 'unsafe-eval'"> and navigation is allowed with permissive configurations: <allow-navigation href="*"/> and cordova-whitelist-plugin is added

Any ideas what may cause the actual login to succeed (so not CORS), content loaded and executed (so not CSP) and requests routed correctly (so not Spring), but nevertheless Tomcat failing to inject the session to the request?

st2rseeker
  • 473
  • 1
  • 5
  • 28
  • It's very difficult to understand the exact issue with the theoretical explanation. Secondly, you referred to a device, what does that mean, you have some Android app on which you are having problem? If it's an app, then you will have to send JSESSIONID for each request to the server. – We are Borg Mar 31 '16 at 15:27
  • I'd love to elaborate, tell me what you'd like to know - just trying to be concise, without dumping here all the configs (most are not relevant, probably). And yes, as I've mentioned - Android 5.0 device. JSESSIONID is sent - when simulated in Chrome all the JSESSIONID transitions are correct; when run on device - JSESSIONID is present, but I am unsure how to check if it the correct one (anyhow - it's HttpOnly, so not something I'm supposed to set manually) - perhaps there is some fault with WebView or with Tomcat, but am unsure how to test it... – st2rseeker Mar 31 '16 at 15:31
  • I don't thinkmso there is some issue with Tomcat. Anyways, can you post the code how you are sending the cookie i.e JSESSIONID to server. – We are Borg Mar 31 '16 at 15:33
  • By specifying this in Angular config: `$httpProvider.defaults.withCredentials = true;` No other tampering with the cookies is done - it's not like I have access to HttpOnly cookies, anyhow, AFAIK. – st2rseeker Mar 31 '16 at 15:35
  • I am sorry, I fail to understand what you say. I hope someone better helps you out. Good luck.. :-) – We are Borg Mar 31 '16 at 15:36
  • I still think its something to with cookie. Check it out. Enjoy – We are Borg Mar 31 '16 at 15:56
  • @st2rseeker Are aware that Phonegap is not a [webserver or a webbrowser](https://github.com/jessemonroy650/top-phonegap-mistakes/blob/master/new-to-Phonegap.md#005)? Are you aware that both [Google and Apple frown on apps](https://github.com/jessemonroy650/top-phonegap-mistakes/blob/master/new-to-Phonegap.md#005a) that are website wrappers? –  Apr 03 '16 at 09:23
  • The app is not a website wrapper (dunno what gave you the impression, though - to be clear all the assets are local and the server is used only for authentication and REST API), however it uses (or rather tries to use) a similar method of login, which is based on a JSESSIONID cookie (among other non-relevant things). Are you implying that HttpOnly cookies don't work in webView as well? – st2rseeker Apr 03 '16 at 10:48
  • And for your information (straight from your link): "Provide a webview of a website not owned or administered by you (unless you have permission from the website owner/administrator to do so)" - does not apply if the site _is_ administered by me. :) – st2rseeker Apr 03 '16 at 10:50
  • Apparently this is _not_ relevant to HttpOnly cookies such as `JSESSIONID` – st2rseeker Apr 03 '16 at 13:11

1 Answers1

0

Well, after some more prodding and thinking, this issue was that JSESSIONID was not being generated prior to j_security_check authentication call but only after it, thus not having an option to retrieve the original session login was made with - subsequent calls were made with inadequate/incorrect identifier.

This link was very helpful: Under what conditions is a JSESSIONID created?

The TL;DR version is that JSESSIONID is not created automatically by default - you have to do one or more of the following things:

  1. Config your server accordingly
  2. Call request.getSession() or request.getSession(true) manually in server code
  3. Get JSP page (there is an implicit request.getSession() there, unless you direct it to behave otherwise)
Community
  • 1
  • 1
st2rseeker
  • 473
  • 1
  • 5
  • 28