That must be specific to the server you're using... Also if you ever need to scale to a Web Farm that won't work...

BUt it may work for you...

+++ Rick ---


>SSL_SESSION_ID is the environment variable passed from server to my CGI app.
>It contains hex-encoded SSL session id .
>Probably this id is unique for each user for all its connections until user closes browser window.
>
>So I don't need to build infrastructure. This is already built by SSL
>layer. I simply use it.
>
>>Where are you going to store this session Id and how will you track that? You will have to build this infrastructure yourself to make this work...
>>
>>But yes, that's the most common approach to take. You have people log in, then set an app internal session id of some sort to identify the user and if he's not identified yet send him back to the login page - preferrably with a back link so that he can still go where he wanted to originally.
>>
>>+++ Rick ---
>>
>>
>>>I wish to thank Michael, Claude, Rick and Brian for replying to my message.
>>>
>>>I try to use the following authentication method.
>>>
>>>Assuming that
>>>
>>>1. I have a fox table with three fields: user_name, password, ssl_session_id
>>>
>>>2. I use SSL protocol always in browser.
>>>
>>>3. Each user is allowed to login only once to my VFP CGI app.
>>>
>>>
>>>my authentication method proposal is:
>>>
>>>1. In beginning of every method, seek Users table for a SSL_Session_Id. If found, continue processing.
>>>
>>>2. If SSL Session Id is not found, send a HTTP Redirect to a
>>>login form.
>>>
>>>3. Login form returns two form variables:
>>>Username and password.
>>>Login form action script handler seeks users table for returned user name and compares the password. If this is OK, it stores the ssl session id to users table SSL_Session_Id field.
>>>
>>>I have little knowledge about SSL Session Id behaviour.
>>>
>>>It this authentication method OK ?
>>>
>>>Will each SSL Session will present a unique ssl session id
>>>from browser to a CGI app ?