Combining PrettyFaces and PicketLink

Question

When using PrettyFaces/Rewrite to rewrite URLs in a JSF application and PicketLink to secure it, PicketLink does not seem to use the rewriting rules.

For example, if I configure PicketLink with something like this:

builder
    .http()
        .allPaths()
            .authenticateWith()
                .form()
                    .loginPage("/common/login.xhtml")

And have a rewrite rule like this:

<url-mapping id="login">
    <pattern value="/login" />
    <view-id value="/common/login.xhtml" />
</url-mapping>

The user will be redirected to /common/login.xhtml instead of /login.

I know that I could use /login as loginPage in PicketLink but, until now, I have been able to use PrettyFaces/Rewrite in a totally transparent way for my application (I could remove it and everything would still be working... but with ugly URLs).

I noticed that the SecurityFilter from PicketLink seems to come before the RewriteFilter from PrettyFaces/Rewrite:

    at org.ocpsoft.rewrite.servlet.impl.HttpRewriteResultHandler.handleResult(HttpRewriteResultHandler.java:41)
    at org.ocpsoft.rewrite.servlet.RewriteFilter.rewrite(RewriteFilter.java:268)
    at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:188)
    at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
    at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
    at org.picketlink.http.internal.SecurityFilter.processRequest(SecurityFilter.java:346)
    at org.picketlink.http.internal.SecurityFilter.performOutboundProcessing(SecurityFilter.java:237)
    at org.picketlink.http.internal.SecurityFilter.doFilter(SecurityFilter.java:196)

So, if PrettyFaces is wrapping the HttpServletResponse somehow to override the encodeRedirectUrl(), the SecurityFilter will not see this wrapped response as it comes before.

Is there a way to make the RewriteFilter come before the SecurityFilter?

I didn't declare those filters in my deployment descriptors, they are being automatically registered via a web-fragment.xml for PrettyFaces and via a @WebListener for PicketLink.

score 1 · Answer 1 · answered Jul 25 '16 at 16:33

1

You could try to add an absolute-ordering element to your web.xml to control the ordering. Something like:

<web-app> 
    ... 
    <absolute-ordering> 
        <name>com_ocpsoft_rewrite</name> 
        <others/> 
    <absolute-ordering> 
    ...
</web-app>

answered Jul 25 '16 at 16:33

chkal

5,598
21
26

Correct! Use absolute-ordering to fix this. – Lincoln Jul 26 '16 at 14:32
This does not work: `SecurityFilter` still comes before `RewriteFilter`. I think this comes from how the 2 frameworks register their respective filters: PicketLink registers its filter from its `PicketLinkServletContextListener` while Rewrite does it in `web-fragment.xml`. I think all `ServletContextListener`s are processed first (so PicketLink registers its filter), then all other filters from DDs are added (Rewrite). So ordering has no effect here. I have set breakpoints both filters and `SecurityFilter` is initialized/chained before `RewriteFilter`. – Xavier Dury Aug 24 '16 at 14:29
A possible solution would be for Rewrite to register its filter from its own `RewriteServletContextListener`. – Xavier Dury Aug 24 '16 at 14:38
I managed to get the filters in the right order by declaring them both either in `web.xml` or in a custom `web-fragment.xml` that is absolutely ordered as #1. Unfortunately, this does not fix my problem: when PicketLink redirects to the login page, the url is not rewritten so this could be a problem in PicketLink (not using `encodeRedirectURL()`?). – Xavier Dury Aug 25 '16 at 06:52
The problem probably comes from `org.picketlink.http.internal.authentication.schemes.FormAuthenticationScheme.forwardToLoginPage()` which does not encode the URL before redirecting. – Xavier Dury Nov 23 '18 at 12:34

Combining PrettyFaces and PicketLink

1 Answers1