Re: Actions - design question + an offtopic question

2000-11-28 Thread Joe Peer

wow.thanks for the explanation!!

joe




RE: Actions - design question + an offtopic question

2000-11-27 Thread Malcolm Davis

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"

Re: Actions - design question + an offtopic question

2000-11-27 Thread Craig R. McClanahan

Malcolm Davis wrote:

 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'

In what way do you feel that Struts should support this?  It's completely
defined by the way you configure your web.xml file (and your server), and
Struts-based applications can take advantage of that fact with no code changes
at all being necessary.  This is true on *any* servlet container that implements
2.2 or later, not just Tomcat.

One reasonable follow-up question is "why does the example application do its
own login processing?".  And the answer is based on a longer discussion from
earlier today -- the interface between a servlet container and the underlying
database of users and roles is not portable, and I didn't want to have to
research how to set that up on every single server that Struts might be run on.
The whole idea of an example application is to be able to drop it in and run, as
a quick test to make sure that Struts works in your environment.


 Thans,
 Malcolm

Craig