You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "V. Cekvenich" <vc...@basebeans.com> on 2003/01/25 21:09:30 UTC
Re: Need input about user authentication with user self registration
strategies
inline
John Cavacas wrote:
> Hello everyone,
>
> I'm currently in the planning/proof of concept stages for my second Struts
> based web app. My first Struts app was pretty small and simple, so I'm still
> new at this.
>
> I spent most of last night looking through the mailing list archives and
> searching on the web to find out about the best strategies regarding user
> authentication in regards to Struts and J2EE (Servlets/JSPs) are concerned.
> I think I have a pretty good understanding of all of the alternatives out
> there. From CMA to Filters, to checking for a user session in a BaseAction
> class, and some other alternatives. My problem is that I'm not sure what is
> the best way to deal with a specific requirement that I have in my
> application. First the requirement. My application is a simple news/article
> posting web app. I need to be able to let a user (based on permissions) to
> edit, delete or archive, an article from the main page, or the article view
> without going into the "admin" area. Picture a news item with buttons for
> edit, delete, or archive and possibly other administrative functions in the
> future. This would use the same JSP as other users would view, but of course
> these other users would not be able to see the admin functions. The
> application has its own user database table, and also a roles table from
> which the permissions are based. These are Admin, editor, contributor,
> registered.
>
> My preferred method to do this would be to use CMA with form based
> authentication, since I could use it even at the action level. I could use
> the Servlet API to detect user roles. However, I also have the requirement
> that users can self register and maintain a profile. Tomcat's JDBCRealms
> looks interesting, but how standard is that feature in other containers? It
> also looks like the database tables required for JDBCRealms have to have a
> certain layout which my current database layout doesn't match.
Create a view that does.
I would also
> like to keep the application as portable as possible across containers.
>
It has to be, with any J2EE based container, which I think is all of them.
> Using a Servlet filter also seems interesting, but it leaves the problem of
> having to decide at the JSP level how to show the "admin" actions. The same
> issue is true with using a BaseAction approach.
Not standard. Look at action - mapping, which uses CMA.
Like you said, just do is_user_in role in action, KISS and then extend.
hth,
.V
>
> I would really like to avoid a messy set of if/elses in the JSP to have this
> done. I've even thought that maybe I should create a custom tag for this.
> But I figured I would shoot these questions out to the list before I decided
> to go down that path. Sticking a user object into a session object is the
> usual way which I have solved this problem in the past using things like PHP
> and ASP (ack!) and of course the same thing could be done here too. But I
> would really like to use a better approach for this application and remove
> any application logic out of the View.
>
> Any suggestions or ideas that I should consider?
>
> Thanks for reading, I know it's long.
>
> John
>
>
>
> This communication is intended for the use of the individual(s) or entity it
> was addressed to and may contain confidential and/or privileged information.
> If the reader of this transmission is not the intended recipient, you are
> hereby notified that any review, dissemination, distribution or copying of
> this communication is prohibited. If you receive this communication in
> error, please notify the sender immediately and delete this communication
> from your system(s) to which it was sent and/or replicated to. (c) 2002
> Sapiens Americas Corp.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>