> Derek Ward - Acegi may be interesting, but it looks to complicated for me
to look much into right now.
> It also seems to be tied to Spring, and I'm not using spring. And finally,
> I'd really kind of rather handle
> security in my actions rather than having security in yet-another-layer
> somewhere in the code.
Here's what you should be doing here.
Simply put, you should be relying on the Servlet model for Security and
leave the implementation to a 3rd party (i.e. the container or Acegi, or
whatever).
The Servlet model is basic, but quite functional. If you want something
beyond what it offers, then you should implement that model on top of the
Servlet model. This leaves the Servlet model as your foundation.
The Servlet model has 2 methods. That's it. It doesn't get much simpler than
that. The two methods are HttpServletRequest.getUserPrincipal() and
HttpServletRequest.isUserInRole().
getUserPrincipal gets you, essentially, the user Login ID. isUserInRole()
takes a role name as a string and returns true if the user is indeed in that
role.
Why would you want to use this? Simply because it's standard to the platform
and your application will port to different containers as well as different
authentication/authorization schemes. It will port because it's completely
ignorant of all of them.
Your code basically punts all of the detail of security to
HttpServletRequest. So what does this mean?
Well, if you use container security, and it works for you, then you get
access to authentication and authorization "for free", with a few container
specific bits (like the Tomcat realms) and some web.xml magic.
If container security won't work for you, then something like Acegi will
support this model as well.
If you don't like either of those and want to write your own (say the
StripesSecurityFilter from the Bugzooky example), then just tweak the filter
to send your own HttpServletRequestWrapper that implements the
getUserPrincipal and isUserInRole methods properly.
You can still have programmatic control to your logic (just wrap code up in
isUserInRole checks, using whatever mechanism you like -- simple if's,
interceptor patterns, custom filters, whatever).
A lot of folks don't like container managed security for assorted reasons.
But that doesn't mean the basic model of the Principal and isUserInRole is a
bad model. It's a fine model. So, while folks may toss out container managed
security, there's no reason to toss out the actual Servlet Security model.
And regardless of the actual implementation of security on the outside of
the application, this model will port.
> Gregg Bolinger - Thanks for the concrete example. My problem, though, is
> that I'd rather not have
> my jsp's hidden away in the WEB-INF directory for two reasons:
> 1. I don't want to have to write actions so the user can access jsp's that
> don't actually need actions
> 2. While not that unusual, if I can I'd prefer to leave them in the
> default location so I don't have
> to hunt them down later.
You can have a pre-action Forward or Redirect any place you want.
return ForwardResolution("/test/ViewQuestion.jsp");
The primary reason that folks bury JSPs in to the WEB-INF folder is that
it's the only folder that essentially guaranteed by the container to be
inaccessible to a client browser. i.e. There's no way the container will
serve up the raw text of the JSP file from the WEB-INF folder, because the
container refuses to acknowledge the existence of that folder in the first
place. If you have ViewQuestion.jsp in the /test directory, there may be
(through some chicanery or trickery) a way to convince the container to
serve up the file as a text file rather than executing it as a servlet.
Problematic if you perhaps have passwords or other sensitive information in
the JSP.
It also prevents the user from directly accessing a JSP from the browser,
even if it does execute the code rather than dump the text, when the user
makes the request, it may be an inappropriate time for it (depending on what
the JSP does).
In my webapps so far, they're small enough that I have all my JSPs in a
single flat directory, and all my actions in a single package. But through
the use of @UrlMapping with the actions, I actually have the actions divided
in to 3 separate areas, for the sake of security. So while my internal
project structure is quite flat, the view to the user is in three different
sub-contexts off of the main webapp. But then I use pre-actions for
everything. The user nevers seens .jsp url in his browser. It's nice using
the UrlMapping to control the logical presentation of the application rather
than being forced by a file hierarchy.
For me, the primary reason I use pre-actions is simply that I don't want my
JSPs to have any affect on the state of the server. They are simply view
only. useActionBean CAN BE (not necessarily is) used to call events on the
action bean which CAN BE used to alter server state.
The way I see it, I need to have the action code anyway (doing whatever it
is that the useActionBean call is going to do), so I may as well take the
JSP completely out of the loop. For me, it cleans the entire project up, and
lets the JSPs be simpler since they have less vested in the overall process.
--
View this message in context: http://www.nabble.com/Basic-pre-action-question-tf3030916.html#a8460667
Sent from the stripes-users mailing list archive at Nabble.com.
|