user « Page « JSF Q&A

1. How to avoid user access to .xhtml page in JSF?    stackoverflow.com

I am new to JSF and writing first simply jsf web app. URL with .jsf are mapping to .xhtml files in WebContent but why I can open .xhtml in web browser with ...

2. Best way to implement user login page in JSF    stackoverflow.com

What's best way to implement login page in JSF 1.2? If session is timeout, use will be redirected to login in page. i found 2 ways to do it on ...

3. JSF 2 - page access depending on user role    stackoverflow.com

Currently using: JBoss 6 (Development on GlassFish 3.1), JSF 2.0, form-based authentication with JAAS (no "public" pages, everything needs authentication). The web application provides two different search pages (like search1.jsf and search2.jsf), ...

4. How to pass the ID of the current user rendered on the page to an action handler method in JSF 2?    stackoverflow.com

I have a JSF page in which I show the details of a given user:

<h:form>

    <p>
    <h:outputLabel value="User Name" for="userName" />
    <h:outputText ...

5. How to redirect to another page when already authenticated user accesses login page    stackoverflow.com

I was wondering if it was possible to redirect users if a certain c:if clausule is true?

<c:if test="#{loginController.authenticated}">
 //redirect to index page
</c:if>

6. How to hide or display jsf pages based on type of user question    coderanch.com

7. JSF page properties on user request    coderanch.com

The Filter mapping that you specify in the web.xml will decide whether to route all your requests(/*) or requests to a specific servlet(LoginCheck). Also, you can map your filter to more than 1 servlet and you can map several filters to 1 servlet too. Your form action can be another servlet if you do not wish to filter the requests

8. Save option when user tries to navigate to other page    coderanch.com

9. JSF page restriction on user roles.    coderanch.com

The J2Ee standard container-managed security system is very good for this purpose. For one thing, it puts the responsibility for controlling access on the webapp server and not on the webapp, so an ill-intentioned user cannot even ram a bad URL request into the webapp, since the appserver will reject it before it can be passed to application code. I commonly ...