Can a single session be used between a java app and browser

[Bharath]

I am a newbie to java and web application and so this question
might sound silly to some of you. Anyway, this is the
scenario I have.

I have a web application running on Tomcat and it has digest
authentication. This webapp has two categories of resources:
resourceCat1 and resourceCat2.

The client would access
o resourceCat1 via a java application, and
o resourceCat2 via web browser interface

The requirement is that the user is prompted for username/password
when he tries either of these resources. But once he is
authenticated on either of these, he should not be prompted
to enter the credentials again when he tries to access the other
resource. It is almost like carrying a httpsession between
java app and web browser -- similar to yahoo messenger and yahoo
mail where if you login on yahoo messenger it can keep you logged
in for yahoo mail as well.

So,

1. User starts client java app. It sends out a http GET request
for resourceCat1.
2. Server challenges the client
3. Client prompts user for username and password.
4. Client enters information
5. Client responds to server with MD5 hash
6. Server accepts and authenticates.

Now, the java app would have a small icon and if you click on
it, it should send a http GET request for resourceCat2. And,
the user shouldn't be prompted for password information again.
So, how can we make the browser aware of the httpsession that
the javaapp has established already.

Can someone tell me if that is possible? I intend to use Firefox
or Internet Explorer as the browser.

--BK

 

[Piotr Gaertig /Gertas/]

[cut]
The requirement is that the user is prompted for username/password
when he tries either of these resources. But once he is
authenticated on either of these, he should not be prompted
to enter the credentials again when he tries to access the other
resource. It is almost like carrying a httpsession between
java app and web browser -- similar to yahoo messenger and yahoo
mail where if you login on yahoo messenger it can keep you logged
in for yahoo mail as well.
[cut]

Append ;jessionid= with a proper session id
to your URL and sent it to a browser. You can grab
this id from a cookie recieved by your java client app.

Cheers,
Piotr Gaertig

 

[Bharath]

Piotr,

I tried your suggestion but it didn't work. When I sniffed the
packet, I found that that this ;jsessionid=.... is actually
sent as part of the GET command. And the server says that
no such resource is available.

Any other clues.

 

[Ross Bamford]

Piotr,

I tried your suggestion but it didn't work. When I sniffed the
packet, I found that that this ;jsessionid=.... is actually
sent as part of the GET command. And the server says that
no such resource is available.

Any other clues.

The jsessionid parameter is part of a wider system that allows stateful
sessions to be maintained without HTTP cookies, using instead URL
Rewriting. However, you may need to set it up in your container - check
the documentation.

In your webapp you might not be able to read the session ID as an HTTP
parameter, because the container will often have parsed it and removed
it, and placed the appropriate HTTPSession reference in your
HTTPServletRequest before calling your Servlet. This is the main point
about this process - it's container managed - just another way of
telling the container which session ID you want.

From the point of view of your webapp, it's possible to completely
ignore the way the session is maintained (cookies or URL Rewriting) as
long as you've stuck to the API, and just retrieve your HTTPSession as
normal regardless of how the browser specified it's number to the
container. In cases where you need to know, however, HttpServletRequest
defines a method (isRequestedSessionIdFromCookie() or similar) that
gives this information.

As for the application end, you would need to obtain the session ID,
either from a cookie (see below) or on returning from your login call
somehow. Then you would append this to your URLs appropriately when
calling out to the server.

A note on the above: I'm not sure that you can mix cookie / url
rewriting, and I'd be willing to bet there's at least one container
where you can't so you should probably read up on this in your
documentation