Pretty Faces and Spring Security 3
Tagged: ball dresses nz
December 7, 2010 at 3:16 pm #17836
I have an issue. I’m using pretty faces and spring security in my app.
The pretty faces filter is first. If I put the spring security filter first then it won’t work.(as in I can access protected pages by typing them in the URL).
This is my app-security.xml
<http auto-config=”true” access-denied-page=”/login/”>
<intercept-url pattern=”/pages/protected/**” access=”ROLE_USER” />
<intercept-url pattern=”/pages/unprotected/**” access=”IS_AUTHENTICATED_ANONYMOUSLY” />
<logout invalidate-session=”true” logout-success-url=”/login/” logout-url=”/j_spring_security_logout”/>
In web.xml I have:
I have the following rule
<pattern value=”/thank-you/” />
When I type in the URL: http://localhost:8080/MyApp/thank-you/ it redirects me to the login page, which is OK. But after I log in, I get to the thank-you page but the URL is not pretty anymore. (I can see /pages/protected/thank-you.jsf)
Any help would be much appreciated.December 7, 2010 at 3:24 pm #20482
Lincoln Baxter IIIKeymaster
In this case, it sounds like you are having an issue where Spring Security intercepts the login-URL when forwarded from PrettyFaces (prettyfaces forwards from
/thank-you -> /pages/protected/thank-you.jsf
I believe you do want Spring Security filter to be first in the chain, and in your security rules you should probably use the top-level URLs like
"/thank-you/"instead of filtering on
"/pages/protected/*". Otherwise, you will continue to have this issue where the forwarded URL is the one that Spring Security saves and uses in the redirect.
You might still wish to block access to .jsf files directly, in which case you should add a rule to the Spring Security filter to this effect. You will also need to remove the “FORWARD” dispatcher from the Spring Security filter in order for this to work, but again, that might not be what you want.
I hope this helps,
LincolnOctober 6, 2011 at 9:04 am #20483
I’ve very same problem as Sergiu’s, I noticed (also here: http://ocpsoft.com/support/topic/problem-spring-security-prettyfaces) that general advise is to place pretty filter *after* spring security filter.
Is this the only option?
We’ve complex authorization subsystem that operates on viewIds (they’re stored in the database, assigned to the users, etc.) so for it to work the pretty filter must probably be placed *before* security filter so that address translation is done in most transparent way.
Can it be configured somehow? Should I alter Spring security’s behavior in any way so that it remembers original, user-visible URLs instead of viewIds and if so — where?
You must be logged in to reply to this topic.