how to keep cookies or sessions between 2 sites?

[Hung Huynh]

Hello,

I have 2 separate web sites on 2 different boxes

www.xyz.com on box 1
www2.xyz.com on box 2

Users log into box 1 via regular ASP/Database authentication, and I keep a
session variable to mark authenticated users.

There's a link that would send users to box #2 at www2.xyz.com. How do I
check whether these users are authenticated or not? I do not want to present
a login screen again. Is it possible? If so, what are ways to do it, if not
session/cookies?

Thanks!

HH

 

[Curt_C [MVP]]

Dont believe so.
Best I could suggest is pass it as a hidden form field or in a DB

 

[Boris Nikolaevich]

Assuming that both boxes have access to the same database, you can use some
text, number, or GUID that uniquely identifies the user's session. When the
user is authenticated against your database through Site 1, store this
identifier in the database and return it to the page which will transfer to
Site 2. The hidden form field suggested by Curt is a good way to do it, as
is encoding it in a query string.

Since I'm not sure I've concisely demonstrated my command of the English
language, here's a walk-through example.

1. User visits www.xyz.com (Site 1) and enters login information.
--> Your script or stored procedure compares login information to the
database.
--> The login info matches, so the script or stored procedure generates the
unique session id 12345678-9012-3456-7890-123456789012
--> The unique id is stored in the database and returned to your ASP script.

2. Your ASP script rolls this unique id into a hidden form field or
hyperlink, such as
<A HREF="http://www2.xyz.com/transfer.asp?UniqueSessionID=<%=
UniqueSessionID %>">Transfer!</A>
-- or --
<FORM NAME="formTransfer" ACTION="http://www2.xyz.com/transfer.asp"
METHOD="POST">
<INPUT TYPE="hidden" NAME="UniqueSessionID" VALUE="<%=
UniqueSessionID %>">
<INPUT TYPE="submit" VALUE="Transfer!">
</FORM>

3. The user clicks the link or submits the form, which takes them to
www2.xyz.com (Site 2).
--> The ASP script "transfer.asp" reads
Request.Querystring("UniqueSessionID") [or Request.Form("UniqueSessionID")
--> The ASP script looks for a matching record in the database for an
authenticated user with UniqueSessionID
--> A match is found, and any permissions/credentials/other pertinent
information is loaded from the database (not from cookies or Session
variables)

3. The user browses around Site 2.

4. The user logs out of Site 2 (or the session times out).
--> In your logout script and/or Session_OnEnd event, you include code to
clear out the UniqueSessionID from the database, indicating that the session
is no longer active.


A couple of final thoughts and notes:
- This is not a 100% hackproof solution, but it should work pretty well for
your needs, especially if the only thing you pass between servers is the
UniqueSessionID and the UniqueSessionID expires when the user logs off.
- Although you're certainly free to write extra code to come up with a
unique or semi-unique session id, there's no reason you can't use the
SessionID property for this particular application. You don't need the id
to be unique across days or years, you only need to identify the
authenticated user during the jump between domains.
- For that matter, if the user is not likely to ever go
Site1-->Site2-->Site1, there's really no need to persist the id in the
database after the initial transfer. You could delete it immediately and
increase security (because it would prevent anyone else from using that id
to connect to Site 2).

That's all I've got for now, though it can certainly be refined. Hope it
helps!

--Boris

 

[Hung Huynh]

Thanks Curt and Boris for a detailed walk-through. I prefer capturing ID in
database table rather than passing it via hidden form field for security
reason. I may even incorporate some sort of time limit between the transfer.
I like Boris's suggestion of deleting ID from table right away after the
transfer, since I can create a new session var with this ID at site2, and
this should persist.

Once again, thank you both.

HH

Assuming that both boxes have access to the same database, you can use some
text, number, or GUID that uniquely identifies the user's session. When the
user is authenticated against your database through Site 1, store this
identifier in the database and return it to the page which will transfer to
Site 2. The hidden form field suggested by Curt is a good way to do it, as
is encoding it in a query string.

Since I'm not sure I've concisely demonstrated my command of the English
language, here's a walk-through example.

1. User visits www.xyz.com (Site 1) and enters login information.
--> Your script or stored procedure compares login information to the
database.
--> The login info matches, so the script or stored procedure generates the
unique session id 12345678-9012-3456-7890-123456789012
--> The unique id is stored in the database and returned to your ASP script.

2. Your ASP script rolls this unique id into a hidden form field or
hyperlink, such as
<A HREF="http://www2.xyz.com/transfer.asp?UniqueSessionID=<%=
UniqueSessionID %>">Transfer!</A>
-- or --
<FORM NAME="formTransfer" ACTION="http://www2.xyz.com/transfer.asp"
METHOD="POST">
<INPUT TYPE="hidden" NAME="UniqueSessionID" VALUE="<%=
UniqueSessionID %>">
<INPUT TYPE="submit" VALUE="Transfer!">
</FORM>

3. The user clicks the link or submits the form, which takes them to
www2.xyz.com (Site 2).
--> The ASP script "transfer.asp" reads
Request.Querystring("UniqueSessionID") [or Request.Form("UniqueSessionID")
--> The ASP script looks for a matching record in the database for an
authenticated user with UniqueSessionID
--> A match is found, and any permissions/credentials/other pertinent
information is loaded from the database (not from cookies or Session
variables)

3. The user browses around Site 2.

4. The user logs out of Site 2 (or the session times out).
--> In your logout script and/or Session_OnEnd event, you include code to
clear out the UniqueSessionID from the database, indicating that the session
is no longer active.


A couple of final thoughts and notes:
- This is not a 100% hackproof solution, but it should work pretty well for
your needs, especially if the only thing you pass between servers is the
UniqueSessionID and the UniqueSessionID expires when the user logs off.
- Although you're certainly free to write extra code to come up with a
unique or semi-unique session id, there's no reason you can't use the
SessionID property for this particular application. You don't need the id
to be unique across days or years, you only need to identify the
authenticated user during the jump between domains.
- For that matter, if the user is not likely to ever go
Site1-->Site2-->Site1, there's really no need to persist the id in the
database after the initial transfer. You could delete it immediately and
increase security (because it would prevent anyone else from using that id
to connect to Site 2).

That's all I've got for now, though it can certainly be refined. Hope it
helps!

--Boris

Dont believe so.
Best I could suggest is pass it as a hidden form field or in a DB

--
----------------------------------------------------------
Curt Christianson (Software_AT_Darkfalz.Com)
Owner/Lead Designer, DF-Software
http://www.Darkfalz.com

keep

a if
not

 

[Matt Simner]

Hi,

I might be missing something here - ASP session state certainly won't
fly between different boxes, but you can persist 'normal cookies'
between boxes on the same domain.

so.. depending on your scheme for authenticating, you could throw a
cookie on box1 with (syntax a bit rusty) a 'domain' property of
'xyz.com', and you would be able to read this OK on box 2. I guess
you could store the 'REMOTE_USER' server variable or a 'session id' or
something similar - not a password of course!!

The other answers about global 'session state' also make a lot of
sense and is how I normally tend to do it (you can't necessarily
assume that people have cookies switched on).

HTH

Matt Simner

 

[Bite My Bubbles]

there are some free com objects that handle this

Hi,

I might be missing something here - ASP session state certainly won't
fly between different boxes, but you can persist 'normal cookies'
between boxes on the same domain.

so.. depending on your scheme for authenticating, you could throw a
cookie on box1 with (syntax a bit rusty) a 'domain' property of
'xyz.com', and you would be able to read this OK on box 2. I guess
you could store the 'REMOTE_USER' server variable or a 'session id' or
something similar - not a password of course!!

The other answers about global 'session state' also make a lot of
sense and is how I normally tend to do it (you can't necessarily
assume that people have cookies switched on).

HTH

Matt Simner

"Hung Huynh" <[email protected]> wrote in message