This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Grails session expires during callbacks from OAuth providersPage Title Module

Grails session expires during callbacks from OAuth providers

Mar 30th, 2012, 11:09 PM

Hi all. The issue I'm about to raise involves a number of moving parts, but I believe I have definitively isolated it to being a core Grails/Spring issue, and not something due to the third parties in play. The basic problem is that when a user starts a session with my application, the session successfully communicates with an OAuth provider (tested with LinkedIn and Twitter), but expires when the browser redirects to the provider's website for authentication.

First, my environment: Oracle JDK 1.6.0.29, 64-bit, running on Ubuntu 11.10, with testing done in IntelliJ IDEA 11.0. I have tested what follows in both Grails 1.3.8 and 2.0.1, and they produce identical results, starting from clean projects with only the oauth-scribe plugin added (I did that to make sure none of my other code was at issue).

Second, the code from the controller that implements the OAuth interaction. It is exactly as written by the plugin author, with only a few print statements added by me:

As you can see, the requestToken stored in the session map disappears because the session id in the authenticate action is no longer in use when the callback action is called. Note that I print all of the session attributes in both actions, and the only attributeBy switching the session map call to servletContext, I get successful authentications, but aside from being bad practice, it suggests very strongly that the user's session is expiring, even with the browser open, as soon as a page that the application itself sent the user to is visited. Since the code works exactly as expected when the session is taken out of play, the only remaining question is what is causing the session to expire. I appreciate any help you all can offer.

Since the plugin installs into a directory that is not part of the path under source control on my local machine, I have copied the modifications I made to the plugin's OauthController file to a file inside the application called MyOauthController.

Interestingly, by redirecting from the controller used in the oauth process to the original controller, the original session ID shows up again, and anything placed in the flash and session scopes in the second session thus becomes unavailable. Here is an example of the output produced by the demo:

//inside OauthController in plugin
session.id is 0EC29A4C722DF5C2CE65BDC284337BCF in authenticate
attribute names for session in authenticate:
oasRequestToken
attribute is a Token? true
url is https://api.linkedin.com/uas/oauth/a...0-cfb72437de11
//inside OauthController in plugin AFTER redirect to LinkedIn
session.id is 9FE7FD8E15BC41C2F7F7100FD383A826 in callback
attribute names for session in callback:
//inside DemoController in main Grails app after request token is found to be null in oauth/callback
flash message is now null
session message is now null
session id is now 0EC29A4C722DF5C2CE65BDC284337BCF in /demo/failure

I am very surprised to see that the original session continues to exist, and that it is somehow automatically recovered by Grails on the redirect to a controller that is never invoked until after the first switch occurs. But as you can see, that is exactly what happens.