aspose file tools*
The moose likes JSF and the fly likes JavaEE embedded security fails when using PrettyFaces. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "JavaEE embedded security fails when using PrettyFaces." Watch "JavaEE embedded security fails when using PrettyFaces." New topic
Author

JavaEE embedded security fails when using PrettyFaces.

Volodymyr Levytskyi
Ranch Hand

Joined: Mar 29, 2012
Posts: 505
    
    1

I have started with prettyfaces yesterday.
And today I have very stupid problems.

I have big register form and this button at the bottom
<h:commandButton id="registerButton" class="registerButton" value="Register" type="submit" action="#{registerBacking.create}" />
Everything was working very well before. But yesterday I embedded pretty-confg.xml and it stopped working
registerBacking.create is not called at all. This method should persist new user and navigate him to secured
page causing FORM based authentication to redirect him to login.xhtml.

The second problem is that when unauthrised user accesses any secured page user is not redirected
to login.xhtml by container security mechanism but is sent directly to that secured page.
ALL this was working very well before I embedded prettyfaces.

Please tell me what to do?


True person is moral, false is right!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

PrettyFaces does not have problems with J2EE container-managed security. The container handles all security issues before dispatching to the webapp and PrettyFaces is part of the webapp, not the container.

Container security rules are pattern-matched against the incoming URL, however, so you may need to add a "redirect" directive to your navigation in order to prevent the previous URL fro being used.


Customer surveys are for companies who didn't pay proper attention to begin with.
Volodymyr Levytskyi
Ranch Hand

Joined: Mar 29, 2012
Posts: 505
    
    1

Hello Tim!

I have just been typing response that it is impossible for container to intercept 'mappingId' if I use pretty:link or 'pattern' if I use h:link when great idea came into my head.
Container security intercepts url-patterns defined in <security-constraint> in web.xml.
I simply added new url-patterns for role I need. And this pattern is identical to pattern defined in pretty-config.xml. It means that if user wants to access his profile he simply should type in browser:
http://localhost:8989/siteName/myProfile
It is all ! Container security at first intercepts this due to '/myProfile' pattern and then pretty-config handles this due to its own '/myProfile' pattern and in reality user is moved to /siteName/user/userProfile.xhtml.
Even more. If I use pretty:link which is necessary if I want to use pattern from pretty-config.xml l just need the same mappingId as 'url-pattern' for javaee security:

This pretty:link creates url that includes '/myProfile' and IT IS intercepted by container security.
I read somewhere that there is no need to use faces-redirect for pretty-link.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JavaEE embedded security fails when using PrettyFaces.