Per-Session Cookies and Java Programs

[TCM]

Hello. I'm currently writing a java program that connects to a website
and reads information from it. Eventually it will return a URL for the
user to go to. The only problem is there are a lot of "per-session"
temporary cookies involved. I haven't found a way to go from the java
program's URL to the URL in IE because of all of the per-session
cookies involved. Does anyone have any idea how I can save the
per-session cookies from java into IE or a way around this? My last
hope is just opening the webpage in the java gui.

 

[Roedy Green]

My last
hope is just opening the webpage in the java gui.

Your cookie needs only a unique int session number. The actual data
can be stored in the server, rather than sending them over and over
with each transaction.

You might want something a little fancier than sessionNumber ++ to
discourage spoofing.

 

[John C. Bollinger]

Hello. I'm currently writing a java program that connects to a website
and reads information from it. Eventually it will return a URL for the
user to go to. The only problem is there are a lot of "per-session"
temporary cookies involved. I haven't found a way to go from the java
program's URL to the URL in IE because of all of the per-session
cookies involved. Does anyone have any idea how I can save the
per-session cookies from java into IE or a way around this?

Your program is ill-conceived. If, as you say is the case, the
information required to access the web page in question includes
per-session information in the form of cookies then it is manifestly
insufficient to attempt to access the page via a URL alone. It is then
also insufficient to hand off a URL to some external application and
expect it to access the page.

It is not generally possible to hand off an HTTP session from one
application to another. This at least partly is by design.

My last
hope is just opening the webpage in the java gui.

Rendering HTML is non-trivial, but you may be able to find a suitable
library to help you. Java GUI widgets understand HTML to some extent,
but AFAIK they do not provide a full rendering engine. I'm afraid I
don't have anything to suggest off the cuff.

 

[TCM]

Yes. The Java Edit Pane does support some rudimentary HTML but nothing
close to the level that I would need it as. Then I would ask to you,
given a similar situation where you need a program to handle some
trivial aspects and filling out form information but then human
interaction to complete the process, can you give me a better idea to
accomplish such a task?

 

[Andrew Thompson]

Hello. I'm currently writing a java program that connects to a website

What site? URL?

and reads information from it. Eventually it will return a URL for the
user to go to. The only problem is there are a lot of "per-session"
temporary cookies involved. I haven't found a way to go from the java
program's URL to the URL in IE because of all of the per-session
cookies involved. Does anyone have any idea how I can save the
per-session cookies from java into IE or a way around this? My last
hope is just opening the webpage in the java gui.

I suggest ..
a) Ask the site owners, if they don't mind you accessing
their site in this way, to provide an alternate access for
your Java application, and if they do mind...
b) Don't access their site using your Java application

 

[TCM]

I was also wondering if its possible to copy the per-session cookies to
the user's cookie folder and hope they are sent the same way as session
ones.

 

[Rogan Dawes]

Your program is ill-conceived. If, as you say is the case, the
information required to access the web page in question includes
per-session information in the form of cookies then it is manifestly
insufficient to attempt to access the page via a URL alone. It is then
also insufficient to hand off a URL to some external application and
expect it to access the page.

It is not generally possible to hand off an HTTP session from one
application to another. This at least partly is by design.

This is not true. A counter example would be Google Talk, which takes
you from the Google talk application directly to your inbox, at a click.
Another recent example is Amazon, which included a session id in the
"unsubscribe" link of an email that they sent me. Conceptually, there is
nothing difficult about this.

The way to do it is to have a session identifier that can be carried
between the thick client and the browser in the URL.

e.g. Log in to the app via the thick client. The app then generates a
SessionID, and gives it to the thick client. When desired, the thick
client uses something like BrowserLauncher to open your browser to a
link that includes the sessionid in the URL. The app sees the request
for that specific page, maybe generates a sessioncookie that is set in
the response, but associates that session cookie with the session that
was created when you logged in via the thick client.

Pretty straightforward, IF you control the server side of things as
well. AND the web app and the thick client are linked at the backend, of
course.

Rogan

 

[Roedy Green]

My last

That seems to be the easy way. You sniff with a protocols sniffer to
figure out how things work, then go to Java where you have complete
control and few unknowns.

See http://mindprod.com/jgloss/cookie.html
http://mindprod.com/jgloss/sniffer.html