aspose file tools*
The moose likes JSF and the fly likes Odd Servlet 3.0 declarative security behavior Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Odd Servlet 3.0 declarative security behavior" Watch "Odd Servlet 3.0 declarative security behavior" New topic
Author

Odd Servlet 3.0 declarative security behavior

Patrick Garner
Greenhorn

Joined: Jul 24, 2001
Posts: 5
I have a security constraint declared in web.xml:

After logging in, when I make a GET request against the application I get the expected behavior e.g.
https://localhost:8443/Patrac/screens/user.xhtml --> results in access denied.
However, when I do a postback e.g.

I can view the screen. If I do a second identical postback, I get the access denied message. Each time I submit a postback the result alternates between displaying the screen and issuing a 403. The URL displayed in the browser alternates between the following:

https://localhost:8443/Patrac/screens/user.xhtml --> browser URL when access denied
https://localhost:8443/Patrac/public/403.xhtml --> browser URL when user screen is displayed

I understand the way the displayed browser URL in JSF lags behind the screen that is currently displayed, so that's no mystery. But I don't understand how I'm able to view the screen every other time the same postback is submitted.

I did try post-redirect-get and that made the strange behavior go away, as expected.

However, I don't want to do PRG every time and besides PRG doesn't eliminate the security problem.

What am I missing here? Thanks for any insights!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Actually, you must use the redirect if you want security to function properly. Security is based on the incoming URL, not on the resources that the URL may tap into. The redirect option ensures that the URL tracks.

However, there's something very questionable about your URLs if they end in ".xhtml". Normally a JSF URL would be in the form "/faces/..." or "....jsf". The FacesServlet would then deconstruct that URL to form the name of the xhtml resource that would be used to construct the View.

Resources paths are not URLs. They just happen to share certain syntactical characteristics.


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

Joined: Jul 24, 2001
Posts: 5
Thanks, now I understand it better. Regarding the ".xhtml" suffixes, it's just a technique so one doesn't have to use security constraints to prevent direct access to source files.
Brendan Healey
Ranch Hand

Joined: May 12, 2009
Posts: 218

It's a funny thing that when you're using suffix mapping rather than prefix mapping FacesServlet appends .xhtml (assuming this is
your suffix) to everything, so you end up with login.xhtml.xhtml and jsf.js.xhtml. This was too weird for me so I switched back to
prefix mapping, but that's not perfect as you're lumbered with the /faces prefix (by default). Presumably this still happens if you
use *.jsf. I guess the /faces prefix could be eliminated with a mod_rewrite rule if you're using an apache server.

I'm pretty sure I've logged a jira against Mojarra about the extra .xhtml appendage.

Regards,
Brendan.
Pat Garner
Greenhorn

Joined: Mar 05, 2004
Posts: 9
@Brendan I didn't have the problem you described and you see my servlet mapping, above, it's pretty straightforward. My browser URLs look like this: https://localhost:8443/Patrac/screens/user.xhtml. I'm using Mojarra/ AS7.
Brendan Healey
Ranch Hand

Joined: May 12, 2009
Posts: 218
Hi Pat, after a nights sleep I see that I misunderstood, it's interesting that you don't see the same problem as me, I've some across
quite a lot of people who have had the extra .xhtml problem but clearly many don't. Maybe a glassfish problem and time to start the
server in debug mode. I won't mess your post up any further.

Regards,
Brendan.
Brendan Healey
Ranch Hand

Joined: May 12, 2009
Posts: 218
Hi Pat, after a nights sleep I see that I misunderstood, it's interesting that you don't see the same problem as me, I've some across
quite a lot of people who have had the extra .xhtml problem but clearly many don't. Maybe a glassfish problem and time to start the
server in debug mode. I won't mess your post up any further.

Regards,
Brendan.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Brendan Healey wrote:
It's a funny thing that when you're using suffix mapping rather than prefix mapping FacesServlet appends .xhtml (assuming this is
your suffix) to everything, so you end up with login.xhtml.xhtml and jsf.js.xhtml. This was too weird for me so I switched back to
prefix mapping, but that's not perfect as you're lumbered with the /faces prefix (by default). Presumably this still happens if you
use *.jsf. I guess the /faces prefix could be eliminated with a mod_rewrite rule if you're using an apache server.

I'm pretty sure I've logged a jira against Mojarra about the extra .xhtml appendage.

Regards,
Brendan.


JSF does not "append" an ".xhtml". The Facelets processor, under the guidance of the FacesServlet deconstructs the incoming URL and rebuilds it as a resource path. Part of that process, when the URL pattern is "*.jsf" is to remove the trailing ".jsf" and replace it with ".xhtml".

If you're getting ".xhtml.xhtml", you should read up on the documentation for resource resolution in Facelets and in JSF.

Actually, I'm not sure that the "/faces/" convention is recommended in JSF+Facelets anyway. I never liked it even before Facelets came along.
Brendan Healey
Ranch Hand

Joined: May 12, 2009
Posts: 218
> you should read up on the documentation for resource resolution in Facelets and in JSF

I would if I knew where to find it!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Brendan Healey wrote:> you should read up on the documentation for resource resolution in Facelets and in JSF

I would if I knew where to find it!


Hey, job security!

Google and I had some fun, and while I found the authoritative docs, they're rather cryptic. The tutorial will probably help more:

http://docs.oracle.com/javaee/6/tutorial/doc/gipob.html#gjjkc

I noted that apparently the default URL patterns are "/faces", "*.jsf" and "*.faces" if you don't explicitly map. In the case of the extension-based patterns, the mechanism removes the indicated extension and replaces it with the URL suffix. In the case of "/faces", the javax.faces.DEFAULT_SUFFIX would simply be appended. A construct such as "/faces/mydir/page2.xhtml" would be redundant, since the /faces part already labels the URL as a JSF URL and the WEB-INF pattern matcher isn't intelligent enough to handle arbitrarily complex regular expressions, which means that you'd end up with "/mydir/page2.xhtml.xhtml". The expected format would simply be "/faces/mydir/page2".
Brendan Healey
Ranch Hand

Joined: May 12, 2009
Posts: 218
Thanks Tim I'll have a read, I've been perplexed by this for a long time now.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Odd Servlet 3.0 declarative security behavior