RE: Need input about user authentication with user self registration strategies

[John Cavacas]

I realize that this is more of an architecture question and probably should
be labeled [OT]. However, I was looking for more of a Struts based opinion
to these issues.

It seems like I will have to roll my own solution for this. As such, I was
thinking of using the Jakarta taglib session. Does Struts have a tag which
would provide me with similar functionality? I might just also create my own
tag for this purpose.

Any insight, suggestions or anecdotes into these issues would be greatly
appreciated.

Thanks again,
John

> -Original Message-
> From: V. Cekvenich [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 3:10 PM
> To: [EMAIL PROTECTED]
> Subject: 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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Need input about user authentication with user self registration strategies

[John Cavacas]

Thanks for your response.
Please see inline

>Create a view that does.

Views are an interesting possibility. However, something like MySQL for
example, doesn't support views. If I was controlling the access to this
functionality in the application then this wouldn't be a problem as I would
be able to "fake" a view in the case someone is running MySQL.

>>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.

>From what I have gathered, not every container supports the JDBC Realm
concept. Resin for example has this sort of concept and it seems to be a bit
more flexible then Tomcat's because you can specify an actual query in the
xml configuration file. This sort of functionality is pretty much non
standard, with the exception of what is in the Servlet specification which
all containers use. However, storing user information and roles in an XML
file is most often not appropriate. I know that other containers, WebSphere
for example, has an interface which you can create for custom authentication
sources.


>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

Agreed. This is what I would like to do. Having actions mapped to security
roles. I'm just not sure that it will be possible and remain portable.

Thanks again,
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:   
For additional commands, e-mail: 

Re: Need input about user authentication with user self registration strategies

[V. Cekvenich]

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:   
For additional commands, e-mail: 

Need input about user authentication with user self registration strategies

[John Cavacas]

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. I would also
like to keep the application as portable as possible across containers.

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. 

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:   
For additional commands, e-mail: