SSL Session
Ryan Casey
successfully used TLS to login to the machine. However, I would like to use
the same session, and log OUT, so that the script can be run again anytime.
So far I have had no luck. Can anybody point me in the direction I should
be looking? The web and sessions and cookies and stuff is not really my
thing :) I think we are using session variables, no cookies.
Ryan
David Bleicher
news:3c34c451$0$1608$8e9e...@news.atx.net...
Ryan,
I'll take a couple of guesses at what you're trying to do below. If you're
doing something else, please post some more details (such as the TCL script
that works for "log in" with the URL/password sanitized as appropriate) and
I'll try to help if I can.
Short answer:
There probably isn't any way to "log out", and this is probably OK.
Long answer:
My guess is that you are using both the TLS and HTTP packages to do one
of the following:
A. Connect to an SSL website and "log in" with a user ID and password (e.g.
by adding an "Authorization" header to the request)
<or>
B. Connect to an SSL website and "log in" with a certificate (e.g. by using
the "-certfile" parameter)
Either way, there is not "really" a session involved. Here's what's
happening when you call "http::geturl":
1) Create socket
2) Perform SSL Handshake over the socket (TLS package sends the cert if
option "B" above)
3) Send HTTP request (HTTP package includes "Authorization" header if option
"A" above)
4) Receive response
5) Close socket
The key is that ALL of the steps above are performed for EVERY request
(every call to http::geturl). Even if you were to immediately request the
same URL again, all five steps would be performed again. Each time, as soon
as the socket is closed (step 5) the "session" is over. If you are using
http::geturl to send/receive the request it will close the socket after the
response has been received. In fact, the chances are very good* that the
server immediately closed the socket as soon as it was done sending the
response. When the socket is closed, both HTTP and SSL are gone, and there
is nothing left to "log out" of. You can think of this as "automatic log
out" or simply as "log out not necessary". Your choice.
*Why very good? The webserver I use (Apache 1.3.20) automatically closes
the socket after sending the response to an HTTP/1.0 request. I'm guessing
(have not verified) that other webservers work the same way. YMMV. Because
the current HTTP package that ships with TCL only supports HTTP version 1.0,
the socket is closed (by the server) after each request.
As an aside, a request using version 1.1 of HTTP causes Apache to keep the
connection open for a configurable (default 15 seconds) period of time to
allow additional requests on the same socket via "keep-alive". As mentioned
above, the current HTTP package in TCL does not support this (yet). If this
seems strange, it is because the (original) HTTP protocol was not designed
to support sessions (or "keep-alive") at all. It was designed to serve a
file (pointed to by the URL) as quickly as possible, and then immediately
disconnect so that it can move on to the next request, possibly from someone
else. Everything relating to "sessions" (session variables, cookies, etc.)
has been "bolted-on" after the fact.
If you think your server is using one of the "bolted-on" tricks for
"simulating" sessions (you mentioned cookies and session variables in your
post) you MUST find out which one. You don't think you are using cookies, so
I will ignore them. As for "session variables", there is no "standard" for
how to do this. These may be passed from page to page (e.g. "mangled"
URLs), stored in the server's shared memory, and/or written to the server's
disk. How this is done is entirely up to your server software (which may
include many pieces: web server, application server, language engine, and
applications).
If your server is using session variables to track a user across multiple
requests, you must find out exactly how it is doing this in order to cause
it to destroy the variables. If it is just passing variables from page to
page (i.e. like CGI parameters), then chances are you won't have to do
anything. Just stop requesting, and it will be the same thing as "logging
out".
If the server is storing these variables in shared memory or on disk between
requests, then you need to know what kind of request (if any) you should
send to have the server destroy them. Most often, when a server uses
session variables, it handles cleaning them up (destroying them) all on its
own. A common approach is to associate a timestamp with the variables that
is updated on every request, and then periodically scan all the timestamps
destroying the variables that are older (haven't been updated) than "xx"
seconds. If the server (or the applications it is running) has been coded
properly, chances are you don't need to do anything.
Finally, it may be that there is an application (CGI script, servlet, ASP,
etc.) on the server that you can call to immediately destroy the session
variables. This would usually be a specific "logout" script. I'm guessing
that you wouldn't have asked the question if it were this simple. :) It
could also be an "admin" script to force a clean-up on demand, instead of
waiting for the timestamps to expire. I'll just say that you need to talk
to the server admin/developer to find out if there is a specific script you
can call (and what parameters you might need to pass it) in order to force a
log out.
Hope this helped. Cheers...
David
---
--
-