• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java application(not browser) and Servlet/HttpSession tracking

 
anandh
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
How does one track a session when a user uses a stand-alone Java Application while requesting a servlet? The servlet is protected by basic HTTP Authentication mechanism and once the user is logged in (from the Application, not the browser), how do we track the session if the user visits any other servlet from the same application?
Apparently the application when first connecting to the servlet1 is asked to authenticat. Once authenticated and tried accessing other servlet, again an HTTP authentication is requested.. the user session is not tracked..
any inputs?
 
Manohar Karamballi
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hai Anand!
Use SessionContext to store Session info and each time user is accessing servlet see whether he is already authenticated using the info stored in Sessionontext and then decide whether to authenticate him or not...
Hope this will help..
Rgds
Manohar
 
anandh
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Manohar,
I think I didn't make myself clearer. I was asking about how the basic HTTP Authentication related to the HttpSession management.
Here's the scenario in detail:
Suppose I have /servlet/ directory protected under Apache/Jserv, any browser or application requesting a servlet in that directory will be presented with an authentication request. The browser handles this and pops up a box to ask for username/passwd. On similar lines, I wrote a Java app which uses Java.net.Authenticator class to handle this request and process it. Everything works fine till here.
Now here's the actual problem:
Now once I access this URL (using openURL) from my application, http://myserver/servlet/servlet1 , it asks for authentication, which my application handles and lets me access the servlet1.
Now when I try accessing http://myserver/servlet/servlet2 , it throws back that HTTP Authentication request.
The same set of servlets: servlet1 and servlet2, when accessed through a browser, show different behavior. While it does ask for authentication for servlet1, once I get past the authentication using browser, when I access servlet2, the webserver does not ask me to authenticate.
Does my problem make sense yet...? Please help.
 
Manohar Karamballi
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hai Anand!
Use setDefault(null)method of Authenticator class once user is authenticated. I am not sure whether it works or not.
Let me know about the result........
Rgds
Manohar
 
anandh
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can tell that it won't work. You just need to set the Authenticator once.. I just read about this authentication and learnt that once the user is logged in , the browser "remembers" the username/password and sends it in the background when the user tries accessing any other servlet. That could be achieved in the Java app also..but the problem is , does this take care of session being tracked from servlet1 to servlet2? I don't think so..
Anyone ?
thanks,
Anand
 
Tim Holloway
Saloon Keeper
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HTTP is stateless, so the only way to track a session - regardless of what's talking to the server - is to pass the session ID back to the client so it can, in turn, pass it back to the server next time in.
There are 2 ways to pass the session ID. The simplest and safest is to put it in a cookie. Of course, if your client can't handle cookies (or if it can, and the user disabled cookies) you have to do this the hard way - via URL rewriting.
Without looking, I think you may find it easiest to take the cookie approach, since they are just another header and you have total control, but if not, just embed the session ID in the response stream somewhere that it can be easily extracted. You don't actually HAVE to do URL rewriting unless this servlet is to be accessed from a browser as well - you just have to make sure it comes back to you and you can identify it.
Note that it's NOT a good idea to get the session ID and cache it - there's not reason why the actual session ID token may not mutate as you go back and forth, depending on the server. I recommend that you only send back the latest one.
 
anandh
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,
Thanks for the input. I understand that I could use cookies or rewriting the URL *PROVIDED* I intend to use that servlet from a *browser*. My application is not interested(or can't handle) in the HTML the servlet would throw at it. So URL rewriting is of no use to me, and if I want to go for cookies, I will have to emulate a browser in the sense..having to implement my own HTTP stack which takes care of the rest of the protocol as well and keep maintaing it! (I came across HTTPClient package : http://www.innovation.ch/java/HTTPClient/ , which can achieve this). But that's not what I want..
I am wondering what else could be done..?


[This message has been edited by anandh (edited September 07, 2001).]
 
anandh
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anybody has previously worked with Java apps opening URL connections (not sockets), and maintaining sessions?
 
PC RE
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
anand,
u could use url rewriting and cookies with java applications also as in ur case.
Try to parse the incomming headers from the server(as part of the response from the server) and use url rewriting (like adding session id or cookie at the end of the url) when making a url connection to a servlet.
Hope this helps.
PC RE
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic