aspose file tools*
The moose likes JSF and the fly likes EL in faces-config to-view-id with MyFaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "EL in faces-config to-view-id with MyFaces" Watch "EL in faces-config to-view-id with MyFaces" New topic
Author

EL in faces-config to-view-id with MyFaces

Rhys Emmerson
Greenhorn

Joined: Jul 23, 2010
Posts: 7
Hi, I recently swapped out Mojarra 2.0 for MyFaces 2.0 in my setup and it was seamless except for one small problem.

In my user authentication system I store the url the user was accessing so I can redirect them back after they log in (you can see the concept here). The problem is that I use EL in the <to-view-id> to grab the url from a bean, this worked in Mojarra but not in MyFaces.

The error I get is below, if the EL was being executed I would expect to either see the EL API in the stack trace or #{userBean.deniedUrl} to be replaced with the url.

javax.faces.FacesException: java.lang.IllegalArgumentException: ViewId must start with a '/': #{userBean.deniedUrl}
at org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
...

Any suggentions are appreciated.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

Actually, you're wasting your time developing something that already exists. The standard J2EE container-managed security system does the URL retention thing, doesn't even require JSF or a specific version thereof, and it's fully-debugged and has proven itself secure over years of use by many users in many places.

And, as I've mentioned a few hundred times in this forum (and other places), I've never encountered a user-designed Java web security system that was even remotely secure. And I've worked with Java webapps since before JSPs were invented.


Customer surveys are for companies who didn't pay proper attention to begin with.
Rhys Emmerson
Greenhorn

Joined: Jul 23, 2010
Posts: 7
Tim Holloway wrote: The standard J2EE container-managed security system does the URL retention thing,


I use tomcat-users.xml for administrative apps and that's fine because there's only a handful of users but I need to be able to have hundreds of users and I didn't think that approach was maintainable.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

No, aside from the sheer logistics of keeping an XML file with hundreds of users in it, the MemoryRealm isn't recommended for production use. If for no other reason than you have to restart the webapp every time you update it.

But that's one of the advantages of container-managed security. The Realms are plug-replaceable without any need to change the webapp itself at all. You can test using a tomcat-users file, but in production you'd typically use something like the jdbc Realm to authenticate users against a database or a jndi Realm if something like Active Directory is more to your taste.
Rhys Emmerson
Greenhorn

Joined: Jul 23, 2010
Posts: 7
Tim Holloway wrote:The Realms are plug-replaceable without any need to change the webapp


Okay, I read chapter 6 of the docs and it sounds more manageable than I thought it was so I'll have a play around with it. I would still like to know what the deal is with EL in to-view-id though.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

I really don't know about that one. Beans don't have URLs, and the URL for a JSF request isn't so much an absolute resource locator as it is a "handle" to the session, as more than one JSF programmer has learned to their sorrow.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: EL in faces-config to-view-id with MyFaces