This "Security" issue has always bothered me.
The servlet API provides a Form Based Authentication via 'j_username' and '
j_password'.
Tomcat supports this feature, but I don't see it in Struts.
Are there plans to support Form Based Authentication via 'j_username' and '
j_password'
Thans,
Malcolm
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 27, 2000 2:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Actions - design question + an offtopic question
>
>
> Joe Peer wrote:
>
> > hi,
> >
> > i just read Craig's answer to denis' question and i was
> wondering if there
> > is some kind of "j2ee compliant" way of doing user auth and
> role-asignment -
> > are there any standards one is supposed to use
> > (i apologize for this offtopic question, since it's not an
> struts issue, i
> > guess)
> >
>
> Well, it's not off topic if you want to use Struts-based apps in a J2EE
> environment :-).
>
> >
> > today i always use my own user/roles tables in my (relational)
> database and
> > i am doing all these things "by hand, means by jdbc queries" - should i
> > change that?
> >
>
> The J2EE recommendation for this is to use container-managed
> security (i.e. the
> <security-constraint> elements defined in web.xml) for user
> authentication and
> access control. Doing so means that the container is taking care of these
> issues for you, and (perhaps more importantly) that user
> identities are shared
> between the web layer and the EJB layer, because the server will
> be using the
> same underlying "database" of users and roles.
>
> The only downside to this approach is that there is not yet a
> standardized API
> for portably accessing and maintaining a "database" of users and
> roles (I'm
> putting "database" in quotes because the actual implementation
> could be pretty
> much anything, including static text files or directory servers).
>
> Instead, most servers provide a server-specific API to do this
> kind of thing.
> For example, in Tomcat you can implement an API called a Realm
> that talks to
> your existing database of users, and then tell Tomcat to use this Realm
> implementation for user authentication. In that way, new users
> added to the
> database (by whatever means) become instantly authorized for web
> use also. If
> you were to switch to a different engine, you would need to
> re-implement this
> function according to the APIs provided by the new server, but
> you would not
> need to update your applications.
>
> >
> > any hint / pointer to doc / suggestions would be nice!
>
> The API that I'm the most familiar with is Tomcat -- if you grab
> the source
> distribution of the "jakarta-tomcat-4.0" CVS module from
> <http://jakarta.apache.org>, look in file
>
> catalina/src/share/org/apache/catalina/Realm.java
>
> for the details of what you have to implement to create your own
> Realm. There
> is even a provided JDBCRealm implementation that lets you connect
> Tomcat to a
> database already -- all you need to do is configure it in the
> conf/server.xml
> file, and there are several examples commented out in the stock
> version of this
> file.
>
>
> >
> > joe
> >
>
> Craig
>
>
> >
> > ----- Original Message -----
> > From: Craig R. McClanahan <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, November 27, 2000 6:37 PM
> > Subject: Re: Actions - design question
> >
> > > Denis Hanson wrote:
> > >
> > > > Hi all,
> > > >
> > > > I am starting to move our existing web application to the struts
> > framework
> > > > and would like to ask a design question.
> > > >
> > > > Here's my problem. After logon, the application user is
> forwarded to one
> > of
> > > > three screens - sysadmin, admin, user. The screen used is
> determined by
> > the
> > > > user's role. (The three screens have no commonality, so I
> don't think I
> > can
> > > > use the one <forward name="success".../> action attrubute
> shown in the
> > > > example application.)
> > > >
> > > > I'm looking for some way to define the various paths in
> > struts-config.xml so
> > > > that the logon action class doesn't have hardcoded paths to
> the three
> > > > role-based screens.
> > > >
> > > > Do I need to create my own ActionMapping class and add additional
> > <forward
> > > > name=/> entries, or is there some other way to do this?
> > > >
> > >
> > > Because we're talking about "what does the logon action
> forward to", you
> > won't
> > > need any additional action definitions. However, you might want some
> > additional
> > > forwards defined. For concreteness, let's assume that your
> three roles
> > are
> > > named "admin", "manager", and "user".
> > >
> > > One approach to this would be to define, nested within the <action>
> > element for
> > > the login action, some forwards that are specific to only this action:
> > >
> > > <struts-config>
> > > ...
> > > <action-mappings>
> > > ...
> > > <action path="/login"
> > type="com.mycompany.mypackage.LoginAction">
> > > <forward name="admin" path="/adminMainMenu.jsp"/>
> > > <forward name="manager" path="/customerMainMenu.jsp"/>
> > > <forward name="user" path="/usrMainMenu.jsp"/>
> > > </action>
> > > ...
> > > </action-mappings>
> > > ...
> > > </struts-config>
> > >
> > > In this scenario, you can do the following at the end of the
> login action:
> > >
> > > String role = ... look up the role for this user ...
> > > return (mapping.findForward(role));
> > >
> > > to forward control to the menu for your user, without the
> action having to
> > know
> > > what the JSP page name is -- only the role name.
> > >
> > > In the example above, the forwards "admin", "manager", and "user" are
> > defined
> > > locally for this particular action, and are not visible to any other
> > action.
> > > You can also define global forwards by nesting them in the
> > <global-forwards>
> > > section instead. When the findForward() method is executed,
> it searches
> > first
> > > in the local forwards for this particular action, and then in
> the global
> > > forwards.
> > >
> > >
> > > >
> > > > Thanks,
> > > >
> > > > Denis Hanson
> > >
> > > Craig McClanahan
> > >
> > >
>
