JSF Pretty Faces

[jaisai vijay]

Hi All,

For the URL handling what is the better approach? Please advice me.

I was googling I found this Pretty Faces. If anyone previously used please provide your experience I mean How is this approach?

Thanks,

[Tim Holloway]

I don't know what you mean by "what is the better approach". Better approach to what? What are you attempting to accomplish?

PrettyFaces is a very useful way to define bookmarkable URLs and to parameterize URLs. It's easy to set up and use.

[jaisai vijay]

Hi,

I have worked on struts in the struts I can have a URLs like http://localhost:8080/example/action.do?id=1 right?

Recently one month back we started a project on JSF. I was searching online to find out about JSF URL configuration like struts. For example I have activation email which will be sent to the user I couldn't get URL to have some user info like user name/key. so that user doesn't have to enter information manually I can configure my bean to get the query param's and bind those values to the properties. I found this pretty faces but I am not sure how much secured it is to have url configuration?

Sorry If I confuse you with my English.

Thanks,

[jaisai vijay]

Hi,

Anyone please help me.

Thanks in advance.

[Tim Holloway]

Anything you put in any URL is insecure. You definitely don't want to put passwords in URLs, and it's a good idea to avoid userID's as well.

However, if you use something like PrettyFaces to allow you to submit a URL such as "http://www.mymessages.com/messages?id=12345" and use a good security system such as the J2EE standard container-managed security system, that's pretty secure. For even better results, don't number message IDs predictably so hackers will have to work even harder to crack the system.

[jaisai vijay]

Hi,

Thanks for your reply.

Tim, are there any other URL rewriting techniques in JSF? I would like to make my application secured.

Thanks,

[Tim Holloway]

If you use the technique I just described, the only further thing you can do to make it more secure is to force the transport to use HTTPS. J2EE container-managed security has a proven track record. The weak spot is in what information you disclose in your URL and that's not dependent on the URL decoder, JSF or even Java. If you use a URL such as "http://www.myserver.com/pages?page=1&user=fredsmith&password=1234", it's going to be insecure because the URL itself is blabbing out secrets for anyone with a network sniffer to read out in clear text. If you use a more discrete URL and require a login, you'll be more secure, regardless of what programming language, framework, or URL decoding scheme you use,

[Tanya Ruttenberg]

My experience with prettyfaces has been very good. We had a long URL with many empty parameters. It took a very short amount of time to write a filter that would filter out all these empty parameters.

The developer of prettyfaces is active on the forum and since he has recently been hired by JBoss, chances are use of prettyfaces will increase.

[Lincoln Baxter]

To answer your question about security -- PrettyFaces is no more or less secure than using any other bookmarking/URL-rewriting/URL-parameterization strategy (of which there are few.)

Any time you accept input from the URL, you are taking a risk because that data comes directly from the user. PrettyFaces does in fact offer a validation feature that allows for convenient validation of URLs using existing/built-in JSF validators; thus, your security improves if you decide to use these features:

It is highly recommended that you use both of these features, so keep in mind that if you decide not to use PrettyFaces, you should still do something like this yourself; again, any data that you accept from the URL is going to be at risk to user attacks - this is not unique to URL-rewriting tools, but you should know that this particular tool makes it easy to resolve these vulnerabilities:

Methods of securing a URL using PrettyFaces:
-- Parameter validation using JSF validators.
-- Parameter restriction using regular expressions.

If either of these validation methods detects invalid data, the default is to abort processing and show the 404 page, just as if you'd entered an invalid URL. If you wish to customize the outcome target when invalid data is detected, you can always do that as well.

Let me know if you have additional questions.
--Lincoln

(Hi Tim & Tanya, glad PrettyFaces is still working out well for you Let me know if there is anything I can do to help!)