Keeping a login state when moving between http and https

[Astra]

Hi All

I've noticed on quite a few ASP sites that when they have a 'MyAccount'
section they transfer the site to https and then when you have logged into
your account successfully and gone back to the majority of the site you move
back to http whilst still being logged in.

I've used the Session var method before to check if a user can have access
to pages, but how on earth can I keep a handle on this when I flip the user
between my standard http to my https sites (and vice versa) when this
effectively loses the Session var (and cookie values for that matter).

If I have to post certain data between the sites then surely this causes
some kind of security breach.

Would I have to do the following:

1) On https, user enters their login and password.

2) These details are valid so I flag a session var on the https to say that
they can order stuff, look at certain pages, etc.

3) When the user clicks one of the page links back to say a Contact us
(http) page then this link must contain the username and password that they
entered.

4) Now that they are back in the http world, I do another DB query to
validate this details and set a session var in the http.

The above seems very messy for 2 reasons:

1) On the https pages I need to build the username/password into every
single visible link that goes back to the http so that I can trap what the
user is going to click on to go back.

2) The session var timeouts for the http and https are going to be out of
sync because the user might be looking at their account for say 5 mins under
https and then go back to the http.

I'm using 1 x MySQL db for my data, cart and to hold the login info.

If anybody has had this problem before and found a way round it, could you
please give me some pointers.

Thanks

Rob

[Astra]

Hi Guys

Any ideas on this??

Rgds

Robbie

"Astra" <in**@NoEmail.com> wrote in message news:40**********@127.0.0.1...
Hi All

I've noticed on quite a few ASP sites that when they have a 'MyAccount'
section they transfer the site to https and then when you have logged into
your account successfully and gone back to the majority of the site you move
back to http whilst still being logged in.

I've used the Session var method before to check if a user can have access
to pages, but how on earth can I keep a handle on this when I flip the user
between my standard http to my https sites (and vice versa) when this
effectively loses the Session var (and cookie values for that matter).

If I have to post certain data between the sites then surely this causes
some kind of security breach.

Would I have to do the following:

1) On https, user enters their login and password.

2) These details are valid so I flag a session var on the https to say that
they can order stuff, look at certain pages, etc.

3) When the user clicks one of the page links back to say a Contact us
(http) page then this link must contain the username and password that they
entered.

4) Now that they are back in the http world, I do another DB query to
validate this details and set a session var in the http.

The above seems very messy for 2 reasons:

1) On the https pages I need to build the username/password into every
single visible link that goes back to the http so that I can trap what the
user is going to click on to go back.

2) The session var timeouts for the http and https are going to be out of
sync because the user might be looking at their account for say 5 mins under
https and then go back to the http.

I'm using 1 x MySQL db for my data, cart and to hold the login info.

If anybody has had this problem before and found a way round it, could you
please give me some pointers.

Thanks

Rob

[Dave Anderson]

Astra wrote:

I've noticed on quite a few ASP sites that when they have a
'MyAccount' section they transfer the site to https and then when you
have logged into your account successfully and gone back to the
majority of the site you move back to http whilst still being logged
in.

I've used the Session var method before to check if a user can have
access to pages, but how on earth can I keep a handle on this when I
flip the user between my standard http to my https sites (and vice
versa) when this effectively loses the Session var (and cookie values
for that matter)...

A demonstration is worth a thousand words. Follow this link, keeping in mind
that amazon.com is one such site:
http://www.amazon.com/exec/obidos/tg.../-/0764516507/

Now note that the URL has been appended with a number that looks something
like this: 104-4100512-5185567 (yours will be different). This number is the
session ID for Amazon, and matches the value in amazon.com's "session-id"
cookie. It is passed in both the URL and the cookie as I navigate the site,
including the secured portions of it.

What is the significance of this? For one thing, it suggests a
self-maintained session architecture, and almost certainly one based on a
database. My requests (each click) never identify me. They instead identify
the session**. I am identified on the back end by matching the session to a
record in the database.

Re-writing your site to use homemade sessions might sound like a lot of
work, but the alternative is relying on ASP sessions, which tend to be
unreliable: http://aspfaq.com/show.asp?id=2157

Ultimately, however, abstracting the session data from the web server's
"sessions" is a winning decision. Besides solving the cross-protocol
problem, it enables you to share session data across domains and across
server farms. Heck - it even allows classic ASP and ASP.NET to share session
data. It is a scalable solution.

**There is more going on than just matching the session ID. You can see this
by opening a different browser (such as Mozilla) with the same session URL.
It would not be unreasonable for them to track my IP address and useragent
strings, for example.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Martin Meredith]

How about placing the session ID in a cookie, at the point of login, and
only at the point of login, and then using that as a fixed session ID ?

Something like

'setting the MySessionID
Session("MySessionID") = Session.SessionID

And from then on in only refer to Session("MySessionID") instead of
Session.SessionID, which could change.

Also doing forget to get rid of the cookie at logout, or timeout.

Any good ?
Martin
"Dave Anderson" <GT**********@spammotel.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Astra wrote:

I've noticed on quite a few ASP sites that when they have a
'MyAccount' section they transfer the site to https and then when you
have logged into your account successfully and gone back to the
majority of the site you move back to http whilst still being logged
in.

I've used the Session var method before to check if a user can have
access to pages, but how on earth can I keep a handle on this when I
flip the user between my standard http to my https sites (and vice
versa) when this effectively loses the Session var (and cookie values
for that matter)...
A demonstration is worth a thousand words. Follow this link, keeping in

mind that amazon.com is one such site:
http://www.amazon.com/exec/obidos/tg.../-/0764516507/

Now note that the URL has been appended with a number that looks something
like this: 104-4100512-5185567 (yours will be different). This number is the session ID for Amazon, and matches the value in amazon.com's "session-id"
cookie. It is passed in both the URL and the cookie as I navigate the site, including the secured portions of it.

What is the significance of this? For one thing, it suggests a
self-maintained session architecture, and almost certainly one based on a
database. My requests (each click) never identify me. They instead identify the session**. I am identified on the back end by matching the session to a record in the database.

Re-writing your site to use homemade sessions might sound like a lot of
work, but the alternative is relying on ASP sessions, which tend to be
unreliable: http://aspfaq.com/show.asp?id=2157

Ultimately, however, abstracting the session data from the web server's
"sessions" is a winning decision. Besides solving the cross-protocol
problem, it enables you to share session data across domains and across
server farms. Heck - it even allows classic ASP and ASP.NET to share session data. It is a scalable solution.

**There is more going on than just matching the session ID. You can see this by opening a different browser (such as Mozilla) with the same session URL. It would not be unreasonable for them to track my IP address and useragent
strings, for example.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use of this email address implies consent to these terms. Please do not contact me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Dave Anderson]

Martin Meredith wrote:

How about placing the session ID in a cookie, at the point of login,
and only at the point of login, and then using that as a fixed
session ID ?

Something like

'setting the MySessionID
Session("MySessionID") = Session.SessionID

And from then on in only refer to Session("MySessionID") instead of
Session.SessionID, which could change.

Also doing forget to get rid of the cookie at logout, or timeout.

Any good ?

I don't see where you're using cookies.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Martin Meredith]

Session("MySessionID") = Session.SessionID ???

Or am I doing something wrong - could this be a session variable ? - Am I
getting mixed up - Oh my brain hurts.....

Martin
"Dave Anderson" <GT**********@spammotel.com> wrote in message
news:uR**************@TK2MSFTNGP10.phx.gbl...

Martin Meredith wrote:

How about placing the session ID in a cookie, at the point of login,
and only at the point of login, and then using that as a fixed
session ID ?

Something like

'setting the MySessionID
Session("MySessionID") = Session.SessionID

And from then on in only refer to Session("MySessionID") instead of
Session.SessionID, which could change.

Also doing forget to get rid of the cookie at logout, or timeout.

Any good ?
I don't see where you're using cookies.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message.

Use of this email address implies consent to these terms. Please do not contact me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Dave Anderson]

Martin Meredith wrote:

I don't see where you're using cookies.

Session("MySessionID") = Session.SessionID ???

Or am I doing something wrong - could this be a session variable ? -
Am I getting mixed up - Oh my brain hurts.....

It most definitely is a session variable, and not a cookie.
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.