Web tier: servlets, JSP, Web frameworks: User authentication & application permissions in Struts
- Posted by: Keeran Hawoldar
- Posted on: February 06 2005 10:32 EST
This is my first post to TSS so I must say thankyou very much to everyone who contributes here as it is making my journey through learning Java & Struts 100x less painful I'm sure.
I am working on a set of applications where I would like to assign module/action accessibility and functionality levels based on the permissions granted to the currently logged-in user. I.E. a particular user won't be able to 'see' certain modules of the web app, or won't be able to perform certain 'actions' within a module.
I am very new to all this, so have been looking for any articles on best-practices or discussions on similar scenarios to make sure I'm not re-inventing the wheel or doing things horrificly wrong.
Can anyone please point me towards any links that might help me out?
Many thanks again,
- Found something by Keeran Hawoldar on February 06 2005 10:55 EST
- extend Struts by Ash H on February 07 2005 09:34 EST
- User authentication & application permissions in Struts by Mikhail Garber on March 03 2005 09:58 EST
It would seem my lack of technical vocab is holding me back - after a few iterations on Google and TSS search I found this:
This is helping so far (and hopefully will help anyone else who's search matches my original post!).
You might want to extend RequestProcessor.It is one of the best practices.It is amazing what you can do in it's method.Look into it's processPreprocess method.
For more info refer...
Ah brilliant thanks Ash.
I had been following a 'CommonAction' method from the Struts Survival Guide book which would mean calling a 'preprocess' method in every action - your suggestion would mean it gets done automatically - even better!
Another solution to this is to use SecurityFilter. Check out www.securityfilter.org
The simpliest solution I have seen is to have all your Actions extend some abstract BaseAction class that calls its abstract doWork (or something) method in the body of the execute method. The real action would implement the method and do the real work. The code in the base action would have the opportunity (just before calling doWork) to apply whatever security policies your application requires: check for user credentials, check if user can run this current action, etc.
You can even create security hierarchy based on the Action class hierarchy: AbstractUnprotectedAction extends BaseAction, AbstractProtectedAction extends BaseAction, AbstractAdminOnlyAction extends AbstractProtectedAction, etc and the code in the BaseAction's execute method can have checks like:
if(!loggedIn(session) && this instanceof AbstractProtectedAction) ...
if(isAdmin(session) && this instanceof AbstractAdminOnlyAction) ...