Using Stormpath and Spring Boot (based on this tutorial), after I've started my server and successfully logged in with my credentials everything works fine. However when I exit the browser and try to open my application I get a redirect loop.
A minimal example is available here as an archive. It's a Gradle project. cd into the directory inside the archive and start the server with ./gradlew bootRun. The app will be accessible at http://localhost:8080. A Stormpath API key is needed for this. Register, get an API key and copy the apiKey-XXX.properties file to ~/.stormpath/apiKey.properties. This way Spring Boot will pick up the file and use it by default (only when you have a single application defined in Stormpath, that is).
Login, then quit your browser (on a Mac don't just close it with the red button, use command-q or right click on the browser's icon and quit it). Restart it and try access http://localhost:8080 once again. That's when I get the redirect loop. Tried it on Mac and Windows, Firefox and Chrome, same happens.
If I open the developer console I can see that first I'm redirected to the login page (fair enough), then I'm redirected to / (wierd) and so on...
When I login the first time I can see that a cookie with the name account is created for localhost and a JSESSIONID too. When I restart the browser the account cookie is intact and JSESSIONID is regenerated by the server. So I guess this behavior is related to the fact that JSESSIONID is bound to the login session or something.
Is there a way to configure this behavior? After a browser restart the user should be a) still logged in or b) be able to log again. Any idea?
Also, on a side note, I'm using an AngularJS app as my frontend. I don't think that should make any difference, but I though it could be important (the example app contains some AngularJS hello world code for this end).
The issue was flagged as a bug by Stormpath and after the release of com.stormpath.spring:stormpath-default-spring-boot-starter:1.0.RC8.1 it is now fixed. See the following answer and the comments for more detail.
I am Stormpath's Java Developer Evangelist.
I was not able to replicate the behavior using your zip file.
However, we have seen this before. It's related to browsers aggressively caching 302 redirects, especially against localhost.
Here's a reference that speaks to the issue in Chrome: http://kmarsden.com/chrome-redirect-cache/
Clearing cache should take care of the problem.
And, this would never happen in a production environment.
