This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes JSF and the fly likes Having serious trouble configuring Authorization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Having serious trouble configuring Authorization" Watch "Having serious trouble configuring Authorization" New topic
Author

Having serious trouble configuring Authorization

Carlos Jorge Tavares Ferreira
Greenhorn

Joined: Dec 10, 2007
Posts: 17
Hi,

I'm facing several issues trying to configure my web app, because nothing is working as I would expect.
I've defined a JDBC Realm on my glassfish v3 installation, and authentication is working properly, redirecting
to the error page when I insert the wrong credentials. So far, so good.

The first problem I've detected is that the app is allowing access to all resources, even those that match the url pattern defined in my security constraints.
It complete ignores the values on my groups table, used in the JDBC Realm.

The second problem is related to the error pages I'm using. I've defined 3 error pages: 403.jsp, 404.jsp and 500.jsp.
If i'm not authenticated and request a resource that doesn't exist (e.g., http://localhost:8080/portal/login.xhtml or http://localhost:8080/portal/login2.jsp), the app shows me the 403.jsp page, as expected. But if I'm authenticated the behavior changes, i.e., if I request a resource that doesn't exist with the xhtml extension, it shows me the 500.jsp, but if I request a non-existing resource with other extension, it shows me the 403.jsp page. But there's an additional problem, both the pages show up scrambled, because the css file and all the images are being blocked.

Here is my web.xml:



And my sun-web.xml:




I've defined 2 users on the DB, one associated with the group 'user' and another associated with the group 'xpto'.
Both of them are able to access http://localhost:8080/portal/faces/secure/home.xhtml

I'm really desperate for help, I don't know what else I can try.

Hope someone can help me figure out what the problem is.

Kind regards,

Carlos Ferreira
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

Welcome to the JavaRanch, Carlos!

It's not a surprise that you'd get a "500" error on JSF page requests if you didn't have an xhtml file that matched the JSF URL. A 500-series error indicates that the FacesServlet ran into an error while processing the request. For a non-JSF URL, the FacesServlet wouldn't be involved.

I'm afraid I can't see how you should be able to retrieve resources that are accessed under the "secure" URL pattern, however. Something you're doing doesn't match what I'm thinking you're doing.


Customer surveys are for companies who didn't pay proper attention to begin with.
Carlos Jorge Tavares Ferreira
Greenhorn

Joined: Dec 10, 2007
Posts: 17
Hi Tim,

Thanks for your reply.

All my pages are under the secure folder, and I only want authenticated/authorized users to access those files.
My main problem right now is that although I specified a security constraint:



Any authenticated user can access a page under that folder (e.g., http://localhost:8080/portal/secure/home.xhtml), even if the user doesn't
have an adequate role.

Am I thinking the wrong way? Isn't the security constraint supposed to block access to those pages?

Kind regards,

Carlos Ferreira
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

Your URL pattern for security is not correct for Faces requests. It would have to be "/faces/secure/*" for that, based on your Faces url-pattern.
Carlos Jorge Tavares Ferreira
Greenhorn

Joined: Dec 10, 2007
Posts: 17
Sorry, my mistake, that was the web.xml I had yesterday.
I've been making several changes to try to make it work and when I replied
to your first post and copied the security constraint from my initial post instead of
copying the one I'm using now, and where both url patterns (Faces Servlet and Security Constraint)
have the same value: *.xhtml
The problem still persists.


The curious thing about this is that if I remove this constraint:


# <security-constraint>
# <web-resource-collection>
# <web-resource-name>Restricted methods</web-resource-name>
# <url-pattern>/*</url-pattern>
# <http-method>DELETE</http-method>
# <http-method>PUT</http-method>
# </web-resource-collection>
# <auth-constraint/>
# </security-constraint>


The application starts having the opposite behavior, i.e., it blocks all users from accessing protected pages...

Any idea?

Kind regards,

Carlos Ferreira
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

I wouldn't use "*.xhtml" as a url pattern if you're using "*.xhtml" resources. It confuses the difference between webapp resources and URLs and may confuse the FacesServlet. It's more common to use something like "*.jsf", so that a "http://localhost:8080/myapp/secure/hello.jsf" resolves to the "/secure/hello.jsf" webapp resource. The URL mapping, as its name implies, works on submitted URLs and doesn't protect resources.
Carlos Jorge Tavares Ferreira
Greenhorn

Joined: Dec 10, 2007
Posts: 17
Hi Tim,

First of all, I would like to thank all your efforts to help me solve this.

Maybe I'm not explaining correctly my problem.

I'll try to put it in a simpler way:

- Two users, userA and userB

userA has one entry on the groups table, associating him to the 'user' role
userB has one entry on the groups table, associating him to the 'xpto' role

Considering this security constraint:



What should happen if both users try to access the page http://localhost:8080/portal/secure/home.xhtml?

Shouldn't the application show the 403 error page for userB, or I'm interpreting the usage of the constraint the wrong way?

Kind regards,

Carlos Ferreira
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

It "should" work that way. unless some other security constraint overrides it. I've done exactly that for years with no problem.

Most likely I'm assuming you're doing something right and you don't know what you're doing wrong. That's the kind of thing that's hard to catch unless you have someone actually watching you do it.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Having serious trouble configuring Authorization