--
Hi Fred,
Fred Whipple wrote:
>
> I've read the FAQ-O-Matic about accessing environment variables within a
> servlet run by JServ, however I'm not getting *all* the variables I'm
> looking for. I've (also with the help of the F-O-M) figured-out how to
> have a standard HTTP authentication window open when a user accesses my
> servlets directly. Creating a servlet that shows the environment as
> well as the JVM properties, I've concluded that JServ isn't passed the
> authentication (or other Web server) variables, such as REMOTE_USER,
> etc.
REMOTE_USER is only set by authentication modules that operate on
requests outside the "handler" phase in which jserv operates.
Consequently, in order to get this you need to use mod_auth (or an
equivalent) and authenticate users against an appropriate database
> I've writing some servlets that will interact with like 30,000 users. I
> want there to be four classes of users, i.e. users, administrators,
> managers, and cashiers. In order to tell one type of user apart from
> the other, I want to have the four groups have usernames associated with
> it (or, actually, by default everyone would be in the "user" group, and
> then just manage the other three). To know just what the user who just
> logged-in can do and can't do, I'd like the servlet to query the
> database to see if the user is an admin or cashier or just a plain
> user. I've not found any way of finding-out who the user is that just
> authenticated using JServ, though.
>
> Two solutions to my own problem would be:
>
> 1. Create separate servlet zones with separate HTPASSWD files and have
> only the relevent users listed in the given servlet zone's
> configuration.
>
> 2. Have the user authenticate via a Web form (rather than the standard
> HTTP authentication) and have a servlet check the HTPASSWD file
> manually, and then pass the appropriate username and group information
> around.
>
> The first solution seems okay, if a little kludgy. It also means a
> larger code base to take care of and slightly increased administration
> overhead due to the four HTPASSWD files. The second solves the problems
> of the first but introduces the need to check passwords using something
> akin to the UNIX Crypt libraries, something not only do I know nothing
> about, but know even less about in Java (even if someone has already
> implemented Crypt in Java).
>
> What I'm looking for is either a way to access the REMOTE_USER and other
> such environment variables from within a servlet (I understand it makes
> things a little platform and Web server dependant) or another solution
> as to how I might authenticate a user and then be able to know within
> the servlet which username I'm working with.
It depends on your requirements of course :) If you can use a static
user database file and do not need to dynamically create users in it,
use mod_auth and REMOTE_USER will be set. There is an alternative
however. I wrote an application in GSP on top of JServ that needed to
create users dynamically in a MySQL database. As it was to be hosted at
an ISP, I wanted the application to be webserver independent,
consequently I could not use mod_auth and had to work out how to
authenticate users.
The options I came up with were 1) session-based auth using cookies and
2) basic auth
In the first case, the login HTML form is processed to check the
username and password and constructs a member object, storing the object
against the users session (something like
request.getSession().putValue(new Member(username)) ). Subsequent
requests use the session ID to lookup the a Member object -
authenticating the request if one is found.
In the second case, as no auth modules are used, REMOTE_USER will not be
set. However when the user submits a username and password, the browser
sends a "Authorization" header that can be accessed via
request.getHeader("authorization"). The format of this header is base-64
encoded "username:password" you have to parse and unencode this header
yourself, checking the username and password against your database. If
the user fails your test, you need to set the "401 UnAuthorized" header
yourself, something like:
try{
[... test your user and throw an exception if the test fails... ]
} catch(UnAuthorisedMemberException ume) {
try {
response.setHeader("WWW-authenticate","basic Realm=\"realm\"");
response.sendError(401,"UnAuthorized");
} catch(IOException ioe){
}
return;
}
It is this header that will pop up the basic auth box in the users
browser.
The problem with both solutions is that EVERY request that needs to be
authorised has to pass through the process and if you have flat HTML
that needs to be authenticated, you must serve it via a HTML module.
In short, if you can use mod_auth it is a lot simpler and easier.
Hope this helps,
Damian
--
Damian Fauth 201 Sussex Street
Software Engineer Sydney, NSW 2000
John Fairfax Holdings Ltd Australia
[EMAIL PROTECTED] Ph. (+612) 9282 3528
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
