• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Session Management not in Browser

 
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Many thanks in advance for any help / advice.

I've been reading a bit about Session Management & Cookies in Tomcat.

However, im not sure how i can maintain state (or have a users session time-out), when connecting from a standalone Java app (NOT in a browser)?

I want users to login with username and pwd, and start a session - from a Java Swing desktop app.

Regards, Sam
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is not a problem as long as you use the HttpURLConnection. HttpURLConnection will automatically manage headers and cookies when you make requests to an HTTP server.
 
sam wootton
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim,

Many thanks for your help, it is very much appreciated.

In my standalone (non browser based) client, i use




All i really want to store is the users username, so that it doesnt have to be sent in requests (XML).

In my Servlet i have (in a login() method):



Elsewhere in the same Servlet i have:



... this is coming out as null.

I have a second question. In my client i make use of HttpURLConnection for some requests (XML), and i also make use of HttpClient for multi-part requests (XML and data).

How would i keep the session the same between these different client objects?

Thank you.

Regards, Sam

 
sam wootton
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
okay, so after a litle reading, i see that maybe artificially sending back a JSESSIONID cookie to the Servlet might be th best (only?) way?

So:

Client > send login (username and pwd) in XML request.
Server > create session and store username.
Server > send back session ID in cookie / header param of HTTResponse.
Client > set that session ID in a the request headers or parameters of subsequent requests to the Servlet?

Would this work? Is it even right?

Regards, Sam

 
sam wootton
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok - i think i have this working.

Servlet:



Client:



Then in subsequent requests to the server i have:



In the Servlet for these subsequent requests:



... i guess i dont actually need to do anything with this, just call:



I havent tested this with different users at the same time.
I havent tested this trying to use HttpURLConnection AND HttpClient.

But i guess i can just set the same cookie on HttpClient?

Regards, Sam



 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe Tim Holloway is right, I have searched in Google about this issue and found something similar what Tim Holloway mentioned. Did you try it?
 
sam wootton
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ekhlas,

This is how i got it working:

Servlet (check to see if use is logged in)




Servlet (log the user in)



This is the bit im sure i've hacked, but it works:

Client (send a request to Servlet). We need to send the JESSIONID back to servlet:



The main problem i had was getting the info from a valid login request (as we dont have Browser doing it for us).

Its a good idea to cycle through the Headers to see what the Servlet has set, e.g.

null=[HTTP/1.1 200 OK]
Date=[Sat, 02 Jun 2012 12:59:26 GMT]
Content-Length=[171]
Set-Cookie=[JSESSIONID=AD6DCE9568F41E787E1217A7AF026090; Path=/musicfinder]
Content-Type=[application/xhtml+xml]
Server=[Apache-Coyote/1.1]




important:

Incoming cookie has Header of "Set-Cookie", but outgoing cookie must be "Cookie".

You must split the whole string:



and send it back formatted.

Regards, Sam





 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are setting yourself up for major pain.

First and foremost, you're attempting to create your own login system and that almost 100% guarantees more expense and less security than if you had used the one that comes built into J2EE.

Secondly, you do not own the session ID. Your server does. How it manages session IDs are mostly internally defined by the server and subject to change without notice, thereby breaking all of your expensively developed-and-debugged (we hope!) security system.

Just to give one example: When you establish a session under the Tomcat Version 6 server and then switch to secure transport (a fairly common case in frameworks like JSF), Tomcat will invalidate that session ID and create an entirely new ID. That new ID will be attached to the original session object, but the original session ID will not.

Short story: avoid at all costs playing with session internals on either client or server sides. The standard HttpURLConnection and J2EE-compliant servers are quite capable of doing everything that's needed without your help. And, more to the point, if you do "help", you can end up doing more harm than good.
 
sam wootton
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim,

Thanks for your reply. I am * very * glad you have pointed this out. So how is the cookie sent back to the servlet without being explicitly set?

There server is 1 Serlvet, and the client has 2 objects (1 DefaultHttpClient and 1 URLConnection).

I dont see how i can get the JSESSIONID back and forth between the two, automatically?

Regards, Sam
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are 2 ways to get a sessionID propagated.

One is via URL rewriting. This is an ugly and fragile process, but it's the only one that works when cookies are forbidden/disabled. You can visually see this as the appended ";jsessionid=...." on URLs.

The other way is via cookies. This is much cleaner and simpler - providing it's not closed off.

If you look carefully, you may see sporadic use of rewritten URLs on a lot of websites, including the JavaRanch. In many cases, however, once the app is certain that cookies are available, the jsessionid disappears from the URL.

Cookie creation and transmission for session IDs is automatic, for the most part. On the server side, as I mentioned, Tomcat will handle it without any application code involvement at all. As it should, since sessions are provided by the server, not the application.

On the client side, as I mentioned, cookies are handled automatically when you use the higher-level network functions. The only really tricky part is ensuring continuity such that the cookie coming from the server with the sessionID in it gets added to the cookie set going back to the server on the next request.

Unfortunately, I don't have any sample code handy from when I made this happy discovery. However, I think that this may be useful: http://stackoverflow.com/questions/2793150/how-to-use-java-net-urlconnection-to-fire-and-handle-http-requests
 
sam wootton
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim,

Many thanks for your speedy response.


The only really tricky part is ensuring continuity such that the cookie coming from the server with the sessionID in it gets added to the cookie set going back to the server on the next request.



... but thats all i am doing. I'm not doing any extra / own solution work at all.

I have left everything to be automatic on the Servlet. The only tricky bit of code was on the client (as i posted):



Regards, Sam
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, you shouldn't have to do even that much. If you're using a sufficiently high-level API, the cookies should come back as name/value pairs and not require you to split them manually out of headers.

Then again, the whole point of the HttpSession object is that it should be collecting the incoming cookies and automatically posting them out on session URL requests without any coding at all on your part. Obviously this means that you need to use the HttpSession as the URL request factory and not simply construct them directly, but that in fact is how it's supposed to be done. So that the cookies will automatically get injected. Along with any other useful appendages to the request.

BTW, for proper operation, it isn't just the Session cookie that you should be sending back. All cookies should be going back and forth. Subject only to two limitations:

1. Expired cookies are, of course, dropped.

2. Any application-supplied cookies are added or removed at the bidding of the application.

So if, for example, my webapp posted out a cookie to contain your approximate geolocation, you should be sending it back to me on subsequent requests until it either expires or I delete it.

Granted, using cookies this way in a J2EE app usually isn't a good idea, since session objects are less trouble and more secure, but still...
reply
    Bookmark Topic Watch Topic
  • New Topic