File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes JSF Preventing direct access to files Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "JSF Preventing direct access to files" Watch "JSF Preventing direct access to files" New topic
Author

JSF Preventing direct access to files

Stevie Shorey
Ranch Hand

Joined: Dec 10, 2012
Posts: 45

Hi,

I am new to JSF programming.

I am using these files for a login system:

login.xhtml
index1.xhtml
index2.xhtml
error.xhtml


Login is my default page. I want the user to access index1.xhtml and index2 ONLY once they have logged in from login page. Currently, my login system is working but user can directly come to these other pages by typing the direct url. How do i stop this?

Sorry if this is too beginner a question.
Thiebaut olivier
Greenhorn

Joined: Jul 10, 2008
Posts: 14
Hello Stevie,

The solution is to use the notion of "Security constraint" in the web.xml,
you can find resources with Google.

example : http://www.coderanch.com/t/606605/Security/SSL-Adding-security-constraint-web

OR http://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html

Olivier
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

Steve, one of my major blood pressure stressors is that virtually every book on J2EE shows examples with "login code" in them.

I have worked with J2EE since before JSPs were invented, and that's a long time. I've seen more user-designed security systems than I can count, including some in sensitive financial apps and even one or 2 military support apps.

And not one of them was truly secure.

Unless you are a full-time trained security professional, mere cleverness won't help. Most of these DIY systems could be cracked in under 15 minutes by people without any J2EE expertise whatsoever.

Except in very rare cases, I recommend not re-inventing the wheel. Take ThiƩbaut's advice and use the built-in J2EE security. It's there anyway, it was designed by security professionals, it's been debugged years ago, and best of all, a lot of its work consists of preventing attackers from exploiting user code by blocking access at the server level. If they can't reach the code, they can't exploit it.


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

Joined: Dec 10, 2012
Posts: 45

Thanks for the replies but while implementing security-constraint i couldnt figure it out!

I looked into security constraints especially <auth-constraint />

I set this up in my web.xml



Also in faces-config.xml is where i am redirecting pages.



The problem is when i press a logout command in home/adminIndex.xhtml which takes the use to the start page, i am getting a security error.

I shouldnt get this because the logout button takes the user to the /index.xhtml page which doesnt have any auth-constraints attached to it.

A bit of debugging revealed the cause of all these errors is the following line in web.xml

When i remove this, the redirect on the logout button works fine but crucially i can directly access the faces/index files now

Please help, its really frustrating.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

You have made the common mistake of confusing resource paths with URL paths. A resource is a "file" or a "directory" within a WAR. A URL is what the user enters on the client side. The webapp uses HTTP URL requests to construct HTTP Responses, and may reference resources to do so according to whatever rules it wishes. For example, a JSF URL is used as the basis for constructing a Resource path and the Faces Servlet locates the View Template it will use by using that path.

The security mechanism acts on incoming URLs, not on resources. So your view-Id's should be ....jsf, not ....xhtml.

Also. I suspect you are trying to use JSF for your login and loginfail web form pages. Because the container dispatches these pages directly, they don't go through the FacesServlet. Even if they did, the login logic in not user-written code - it's built into the server - so the idea of a JSF login page is questionable at best.

One thing to note in JSF is that since URLs often don't directly track the resources that are requested and since the security system keys on URLs, you should code a "redirect" option on any navigation to a secured page to force the URL to align itself.

Stevie Shorey
Ranch Hand

Joined: Dec 10, 2012
Posts: 45

Tim Holloway wrote:You have made the common mistake of confusing resource paths with URL paths. A resource is a "file" or a "directory" within a WAR. A URL is what the user enters on the client side. The webapp uses HTTP URL requests to construct HTTP Responses, and may reference resources to do so according to whatever rules it wishes. For example, a JSF URL is used as the basis for constructing a Resource path and the Faces Servlet locates the View Template it will use by using that path.

The security mechanism acts on incoming URLs, not on resources. So your view-Id's should be ....jsf, not ....xhtml.

Also. I suspect you are trying to use JSF for your login and loginfail web form pages. Because the container dispatches these pages directly, they don't go through the FacesServlet. Even if they did, the login logic in not user-written code - it's built into the server - so the idea of a JSF login page is questionable at best.

One thing to note in JSF is that since URLs often don't directly track the resources that are requested and since the security system keys on URLs, you should code a "redirect" option on any navigation to a secured page to force the URL to align itself.



Sorry i read your reply many times over, and I still do not fully understand it.
I am directly making .xhtml pages with jsf code in it. Sample code given here:

Do I still need to change the view-id to jsf not xhtml, despite this?

I understand what you are saying about URL path's and resource paths now, as it solves the confusion over why i can access the same file from both / and faces/ directories in the front end.

I am using a managed bean for my logic, this is user written in a tryLogin() method here which checks the given username/password combo in a database and if present, checks the type of this user. If admin, then redirects to admin page, if student, redircet to student page etc. It also displays the full name(retrieved from database) on this welcome page.
This bean is connected to a SQL database using JDBC.
All is working fine: i can log in, access database etc. Im running into obstacles implementing security measures!

Sorry, forgot to mention this is just for a required project so i have to use this combination of technologies.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

You cannot use the builtin security in conjunction with user-written login code. As I said earlier, when the container manages the security, the container also manages the login process. Login is done by the container shunting a URL request for a protected URL aside, having the container present and process the login/loginfail pages, then resuming the original URL request if the login succeeds.

The view-id element values in faces-config are relative URLs (relative to the application context root) without parameters on them. The View templates are xhtml. The FacesServlet is responsible for parsing the URL (.jsf) to locate the corresponding template (.xhtml).
Stevie Shorey
Ranch Hand

Joined: Dec 10, 2012
Posts: 45

Tim Holloway wrote:You cannot use the builtin security in conjunction with user-written login code. As I said earlier, when the container manages the security, the container also manages the login process. Login is done by the container shunting a URL request for a protected URL aside, having the container present and process the login/loginfail pages, then resuming the original URL request if the login succeeds.

The view-id element values in faces-config are relative URLs (relative to the application context root) without parameters on them. The View templates are xhtml. The FacesServlet is responsible for parsing the URL (.jsf) to locate the corresponding template (.xhtml).


Thanks for that Tim. How would you recommend i go about this? All i want is to prevent direct URL access. That is the maximum security i need for this application.
If the user cannot access a file unless i link to it, then thats this taken care of.

BTW, i also researched URL hiding but that requires going beyond the scope of this application and adding a URL reqrite engine using a third-party library or using filters using primefaces/spring/richfaces etc.
As you can see, its not me trying to be lazy/shying away from the work, the effort isnt worth the reward (for lack of a better phrase).
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

I always use container-managed security, so forbidding access to URLs that end with ".xhtml" is sufficient for me.

If you cannot use the container security system, the next best bet is to install a servlet filter to reroute the offending URLs to an error page. But that won't make the app any more secure.
Stevie Shorey
Ranch Hand

Joined: Dec 10, 2012
Posts: 45

Tim Holloway wrote:I always use container-managed security, so forbidding access to URLs that end with ".xhtml" is sufficient for me.

If you cannot use the container security system, the next best bet is to install a servlet filter to reroute the offending URLs to an error page. But that won't make the app any more secure.


Ohhh!! if only i had used it earlier. I had discounted using forbidding all .xhtml files on the basis that i might need to access index.xhtml. Now come to think about it, there is no need for the user to have direct access to that file either! If only i had thought of that earlier.
Will this suffice?



?
Stevie Shorey
Ranch Hand

Joined: Dec 10, 2012
Posts: 45

I tried that constraint but it asks me for authentication as soon as i deploy the app, so i cannot do a constraint just for *.xhtml

Also cannot do one for

/admin/*.xhtml

gives me a build error.
Stevie Shorey
Ranch Hand

Joined: Dec 10, 2012
Posts: 45

BUMP
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

Please don't "bump". We have enough people active at the Ranch that if anyone can give an answer, they will. Especially since you were already the most recent post.

I do not understand what you mean about asking for authentication "as soon as you deploy". The container security system doesn't act unless someone sends a URL to the server.

Incidentally, you are not the first person, or even the first person recently to ask about hiding ".xhtml" resources. You might want to search this forum's history.
Mahendr Shinde
Ranch Hand

Joined: Sep 03, 2011
Posts: 38

You need to create two RESOURCE GROUPS
1. for public /guest without login
2. for logged in users

Apply your security constraints to the second resource.


eg.
mysite.com/ PUBLIC RESOURCES
mysite.com/something/ protected RESOURCE

Java EE Security (JAAS) is very flexible, you may create number of resources and provide different level of security to them!


There is still lot to learn!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSF Preventing direct access to files