Automatically Generating htpasswd files

[David Molloy <mo...@eeng.dcu.ie>]

Hi,
   I'm using Tomcat4.0, Apache 1.3 both as standalone and I'm
working on a University project which uses both.  Currently I'm
stuck on the problem of generating htpasswd files using a servlet.
Does anyone know what should be used to generate up files of
the form :

smithy:HDECzKIIDIiu2
jonesp:ZYTSVZ22bx3Ng

I tried using the following code:

sun.misc.BASE64Encoder enCoder = new sun.misc.BASE64Encoder();
aWriter.write(tempUser.getUsername() + ":" +
enCoder.encode(tempUser.getPassword().getBytes()) + "\n");

but it doesn't seem to be working right - I'm not even sure if
this is exactly what's needed - any ideas please?

Dave


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: tomcat session problem

[Rinku Randhawa <rr...@compunetix.com>]

Tomcat sessions are maintained in two different ways 
cookies -- If the client is capable of maintaining cookies 
url rewriting -- For all the clients that are unable to maintain cookies


The problem that you are facing is with respect to cookies.

When a client sends a request to the server the server looks at the
request header if there are any cookies with the name JSESSIONID.  If
this does exist then the server decodes the value of the cookie with
that name to get the session key and looks up its hashtable of sessions
to get the session.  If the cookie does not exist the server looks at
the url if the url is rewritten with ;jsessionid=<session-key> before
the first ? in the url (before the start of the query string).  If it
does exist then the server uses the key to decode the session from the
hashtable. If none of the above exist the server starts a new session
for the request.

When you start up IE (I believe that you have been working with the
cookies on) the first request that you send in will have some cookie
sent with it.  The next IE window (provided that it is on the same
machine) that you open -- you think that you are opening a new session.
But there is a catch.  All the IE windows most probably share the same
process on a single machine.  This results in both the IE windows
sharing the same per process cookie store.  So the second window (though
you might not know bout it) sends the previous cookie back to the
server.  If you have state variables hooked on to the session then the
server retrieves all the cookies with JSESSIONID in them and starts to
find the session key.  In this case since the cookies are the same the
same session object is retrieved for both the IE windows (IF they are on
the same machine).  

Yet a little bit more complication...Lets say somehow you are able to
send in the first requests with the two IE browsers almost
simultaneously. This means that the server receives two requests from
the two IE browsers almost simultaneously.  Since the server has not
sent in any cookie to the IE process running on the client (these are
first requests) the server will find that none of the requests contain
any cookie in the headers and the urls have not been rewritten.  So it
will generate two different sessions  for the two requests and send the
corresponding cookies to the client.  Now the IE process running on the
client has 2 cookies (one from each browser.  While sending any further
requests to the server (with the same domain name) the client will send
all the cookies that it received from the server.  In this case since it
has two cookies it will send both of them.  The server will retrieve two
cookies with the name "JSESSIONID" in any of the subsequent requests
from either browser.  The decoding of the requests will result in a
randomized selection of any of the sessions (depending on whether the
server looks at the first cookie with the name JSESSIONID and breaks the
loop once it has the session or it processes all the cookies with the
name JSESSIONID... In the first case the session object will correspond
to the first cookie with the name JSESSIONID and in the later the last
one with the name JSESSIONID)

Thus the randomized selection.


There are a couple of tricks for you to try out. 

To verify that the above is indeed happening In your IE turn off cookies
for all internet and intranet.  If in your application you have
explicitly called response.encode(<urls in response>) for all the urls
in the response than all your requests will be encoded. Pls make sure
that you call this (The url rewriting takes place only if client cookies
are disabled or the server properties is set to ignore cookies)



The second way to get about the problem is to turn cookies off in the
server itself.
Open tomcats config directory and in the server.xml (I am working with
version 3.2 so the solution that I mention will contain the
configuration information with respect to 3.2.  If you are working with
version 4.0 take a look at the config file you will surely find the
settings elsewhere)
In that file there will be some lines like 
       <RequestInterceptor 
            className="org.apache.tomcat.request.SessionInterceptor"
            noCookies="false" />

Turn the nocookies="false" to nocookies="true"

This way the server will always use URL rewriting to maintain session
information. 


You should then see all the urls having ;jsessionid=<session-key>
somewhere in them. 

This will help in solving the session tracking problem as the server
will no longer get cookies (and will disregard them even if it gets
them) and will always use url Rewriting for retrieving sessions.



Of course if the two browsers are on different machines then everything
will work fine even with cookies :)

Regards 
Prashant




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>