My apologies to all; this wasn't intended to go to the list.
Ted Neward
Patterns/C++/Java/CORBA/EJB/COM-DCOM spoken here
http://www.javageeks.com/~tneward
"I don't even speak for myself; my wife won't let me." --Me
-----Original Message-----
From: Ted Neward <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, July 05, 1999 10:45 PM
Subject: Re: Remote user information
>Any chance you're (a) familiar with Apache/Linux, and (b) willing to be
>persuaded to talk a newbie Apache admin (old-hand C++/Java coder, but
>new-hand Linux admin) through the process of setting up authorization? :)
>
>Ted Neward
>Patterns/C++/Java/CORBA/EJB/COM-DCOM spoken here
>http://www.javageeks.com/~tneward
> "I don't even speak for myself; my wife won't let me." --Me
>
>-----Original Message-----
>From: Steven J. Owens <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Sunday, July 04, 1999 10:04 PM
>Subject: Re: Remote user information
>
>
>>Annu Singh asks:
>>
>>> I have been trying to get a remote user id in a servlet I have
>>> written. I am using the "getRemoteUser()" function but it returns a
null.
>I
>>> was told to configure my Web server to allow user authentication. I
tried
>>> doing it but have not been successful in doing so, as after making the
>>> changes mentioned in various docs - I still get a "null" value. (I have
>>> tried using ".htaccess" file, htpasswd command, security.authentication
>>> directive etc ... but did not work for me).
>>
>> I'm lightweight on the java/servlet areas, but I can give you a
>>brief overview of user authentication.
>>
>> In essence, there's a standard in HTTP for low-security
>>authentication. You can set up your web server so that certain
>>resources - files, scripts, etc - can't be accessed by a client unless
>>the client authenticates the user by including a username and
>>passwordd with the request. Exactly how you tell your webserver that
>>a set of pages require authentication depends on the particular
>>webserver. Using .htaccess file is one of the most popular
>>approaches, and it's the one Apache uses by default.
>>
>> When the client - the browser - requests that file without
>>including authentication information in the request, the server will
>>automatically respond with a prompt for authentication - a username
>>and password. That prompt also includes information about which files
>>are covered by that particular authentication requirement.
>>
>> Typically the browser will pop up a username & password prompt
>>the first time the server requests authentication, then remember that
>>username and password and automatically re-send them when it asks for
>>further pages from that "domain" (domain in a general sense, not the
>>internet DNS sense; if the authentication is required for a directory,
>>then it's also required for all pages in that directory and all
>>subdirectories, etc).
>>
>> With CGI scripts, the web server stores the username in an
>>environment variable that's in the environment the CGI script inherits
>>when it starts up. With servlets, you have to use a method to request
>>the username. But the information won't be there unless you define
>>the servlet/page as requiring authentication.
>>
>> From the server's "stateless" point of view, each request for an
>>authentication-required page is a brand new request, with a brand new
>>username & password conversation between the server and the client
>>required. But the browser handles resending the information behind
>>the scenes, proactively, beating the server to the punch without
>>bothering the user. This only lasts as long as the browser is in
>>memory, though - unlike cookies, the browser won't save the
>>information between sessions (cookies with no defined expiration date
>>also handled this way).
>>
>> Something to note is that the username & password aren't sent in
>>a very secure fashion. The "scheme" most browsers use is base64,
>>which I've read isn't very secure. I don't know if/how that changes
>>if you make the browser get authenticated page from an SSL server. I
>>suspect that SSL protects it more, since it stands for 'secure SOCKETS
>>LAYER', and hence it would protect the request headers as well as the
>>request body. But you'll have to do your own homework there.
>>
>>Steven J. Owens
>>[EMAIL PROTECTED]
>>
>>__________________________________________________________________________
_
>>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>>of the message "signoff SERVLET-INTEREST".
>>
>>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>>Resources: http://java.sun.com/products/servlet/external-resources.html
>>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
