I am using j_security_check to authenticate users which works fine.
When the user is not logged in and tries to access a protected page they are redirected to the login page as expected. When the login suceedes the resource query string parameter is used to forward them to the original protected page.
This works without issue on the publish instance.
The problem I have is our dispatcher has several rewrites e.g for removing html extension and replacing with /
These redirects (301s) are cached.
Therefore if a user tries to a protected page say /protected/page1, they are taken to the login page, when they login successfully the cached 301 for the /protected/page1 is actually the login page.
Has anyone else encountered this?
Can I treat unauthenticated attempts to access pages differently to prevent this issue?
However, it appears to be hitting the Sling Authentication Handler before the dispatcher/auth_checker (?) meaning that I cannot handle redirects differently for restricted pages. I get a 302 redirect for the restricted page and the first page that hits the auth_checker is the login page.
All I want to do is avoid being stuck in a loop when I:
* Request a restricted page
* Get redirected to login page
* Login successfully
* Should go to resource originally requested, actually goes back to login page.
Has anyone encountered problems with this in the past?