Home > Archive > ASP > August 2007 > Moving from ASP Sessions to Database Sessions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Moving from ASP Sessions to Database Sessions
|
|
| Bookham Measures 2007-07-23, 6:56 pm |
| Hello
We are planning to set-up a load balanced web environment. Accordingly, we
are going to change the session management on our website from the classic
ASP Session State and session variables, to a database method.
Does any one have any pointers as to how I might approach this, so that I
can have the same sort of functionality the ASP sessions give without having
to create database columns for each session variable I wish to create.
I am thinking along the lines of some serialised dictionary or something
that I can stick in a blob column.
Thanks in advance
David
| |
| Bob Barrows [MVP] 2007-07-23, 6:56 pm |
| Bookham Measures wrote:
> Hello
>
> We are planning to set-up a load balanced web environment. Accordingly, we
> are going to change the session management on our
> website from the classic ASP Session State and session variables, to
> a database method.
> Does any one have any pointers as to how I might approach this, so
> that I can have the same sort of functionality the ASP sessions give
> without having to create database columns for each session variable I
> wish to create.
> I am thinking along the lines of some serialised dictionary or
> something that I can stick in a blob column.
>
> Thanks in advance
>
> David
The simplest: three columns, with the "Variable..." columns being varchar:
UserID, VariableName, VariableValue
More functionality can be gained by adding a DateCreated and/or DateModified
column
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
| |
| Dave Anderson 2007-07-23, 6:56 pm |
| "Bookham Measures" wrote:
> We are planning to set-up a load balanced web environment. Accordingly,
> we are going to change the session management on our website from the
> classic ASP Session State and session variables, to a database method.
>
> Does any one have any pointers as to how I might approach this, so that
> I can have the same sort of functionality the ASP sessions give without
> having to create database columns for each session variable I wish to
> create.
>
> I am thinking along the lines of some serialised dictionary or
> something that I can stick in a blob column.
I wholeheartedly endorse this decision. It's a great way to share session
information between multiple web technologies (like ASP and ASP.NET), as
well as across servers.
We use two tables: One is common session information (session ID (PK),
session expiration, user ID (optional), and demographics (user agent, IP
address, etc.). The other contains the variables, with session ID and
name-value pairs.
We have been using this for more than three years, and have one regret --
this design does not allow scope limitation. Our next version will have
optional domain & path restrictions, much like cookies have.
--
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.
| |
| Bookham Measures 2007-07-24, 6:56 pm |
| Thank you for the replies guys.
Would you say this method offered any performance benefits on it's own.
Would it be better not to use ASP sessions ever, if it could be avoided.
"Bookham Measures" <bookham_measures_no_spam@yahoo.com> wrote in message
news:%23IIvhDUzHHA.5380@TK2MSFTNGP04.phx.gbl...
> Hello
>
> We are planning to set-up a load balanced web environment. Accordingly,
> we are going to change the session management on our website from the
> classic ASP Session State and session variables, to a database method.
>
> Does any one have any pointers as to how I might approach this, so that I
> can have the same sort of functionality the ASP sessions give without
> having to create database columns for each session variable I wish to
> create.
>
> I am thinking along the lines of some serialised dictionary or something
> that I can stick in a blob column.
>
> Thanks in advance
>
> David
>
| |
| Dave Anderson 2007-07-24, 6:56 pm |
| "Bookham Measures" wrote:
> Would you say this method offered any performance benefits on it's
> own. Would it be better not to use ASP sessions ever, if it could
> be avoided.
I can't imagine that it offers any performance benefit at all. But
performance is really a secondary concern when you want to share session
information across platforms, servers, and applications.
--
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.
| |
| Jon Paal [MSMD] 2007-07-24, 6:56 pm |
| How do you pass/share the PK between ASP.net and Classic ASP ?
> I wholeheartedly endorse this decision. It's a great way to share session information between multiple web technologies (like ASP
> and ASP.NET), as well as across servers.
| |
| Dave Anderson 2007-07-24, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
> How do you pass/share the PK between ASP.net and Classic ASP ?
You don't. You obviously have to use part of the request to identify the
session, but the PK is not required to be the shared information. We use
cookies and demographic information as a basis, and put it behind SSL when
security matters.
--
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.
| |
| Jon Paal [MSMD] 2007-07-25, 6:56 pm |
| I should clarify my question...
I presume either can look up the desired session info from the database.
Where is the common value exchanged between ASP.net and Classic ASP, so the info can be looked up by either ?
"Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message news:OS1Ke5hzHHA.988@TK2MSFTNGP02.phx.gbl...
> "Jon Paal [MSMD]" wrote:
>
> You don't. You obviously have to use part of the request to identify the session, but the PK is not required to be the shared
> information. We use cookies and demographic information as a basis, and put it behind SSL when security matters.
>
| |
| Dave Anderson 2007-07-25, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
> I presume either can look up the desired session info from the database.
>
> Where is the common value exchanged between ASP.net and Classic ASP,
> so the info can be looked up by either ?
In 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.
| |
| Jon Paal [MSMD] 2007-07-25, 6:56 pm |
| So why not put all the session values in the cookie keys and skip the database ?
"Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message news:epShYvszHHA.2484@TK2MSFTNGP06.phx.gbl...
> In a cookie.
[color=darkred]
> "Jon Paal [MSMD]" wrote:
| |
| Dave Anderson 2007-07-25, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
> So why not put all the session values in the cookie keys and skip the
> database ?
That's like asking why people use session variables at all.
--
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.
| |
| Anthony Jones 2007-07-26, 3:56 am |
|
"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot com> wrote in message
news:13af65s52pj96d9@corp.supernews.com...
> So why not put all the session values in the cookie keys and skip the
database ?
>
Because that would place a signficant burden on bandwidth. Every request to
the application would carry all this 'session' data. You also have to jump
through hoops to avoid having this blob of data being sent every time a
piece of static content such as an image is requested.
--
Anthony Jones - MVP ASP/ASP.NET
| |
| Jon Paal [MSMD] 2007-07-26, 6:56 pm |
| um, because the question was based upon sharing sessions.
Here is an elegant solution using cookies....
http://searchvb.techtarget.com/tip/...i951935,00.html
"Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message news:OcbQ0uvzHHA.4816@TK2MSFTNGP04.phx.gbl...
> "Jon Paal [MSMD]" wrote:
>
> That's like asking why people use session variables at all.
>
>
>
> --
> 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.
| |
| Jon Paal [MSMD] 2007-07-26, 6:56 pm |
| Here is an elegant solution using cookies....
http://searchvb.techtarget.com/tip/...i951935,00.html
"Anthony Jones" <Ant@yadayadayada.com> wrote in message news:eOxUzd1zHHA.3564@TK2MSFTNGP04.phx.gbl...
>
> "Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot com> wrote in message
> news:13af65s52pj96d9@corp.supernews.com...
> database ?
>
> Because that would place a signficant burden on bandwidth. Every request to
> the application would carry all this 'session' data. You also have to jump
> through hoops to avoid having this blob of data being sent every time a
> piece of static content such as an image is requested.
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
| |
| Dave Anderson 2007-07-26, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
>
> um, because the question was based upon sharing sessions.
It might have extended the topic, but it still deserves to be examined as a
self-standing question.
Consider session variables in the simplest form. The server assigns
resources to the session and identifies it with a session ID, which is sent
to the browser for use in subsequent requests. The mechanism can be 1)
URL[1], 2) querystring, or 3) cookies. In the case of ASP, it is a cookie.
Does the server send all of the session variables in Response.Cookies? No.
It sends a key to the session, not the contents of the session. The reasons
are myriad, but they include security, privacy, data integrity, practicality
and browser limits on cookie length/number. A session-sharing schema would
necessarily share these concerns, so "putting all of the session values" in
cookies would be just as bad an idea in the shared-session model as in the
single-session one.
Hence, my response. Why do people use session variables at all? The answers
to that question also answer your "why not" question.
[1] Compare these three. Each goes to the same content. The second contains
the session ID, and matches the "session-id" cookie sent when the session
was created:
http://www.amazon.com/dp/0470124482/
http://www.amazon.com/dp/0470124482...157465-0881918/
http://www.amazon.com/Professional-.../dp/0470124482/
--
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.
| |
| Dave Anderson 2007-07-26, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
> Here is an elegant solution using cookies....
>
> http://searchvb.techtarget.com/tip/...i951935,00.html
I would not call that elegant. For one thing, it fails to address load
balancing.
It is sufficient for sharing between ASP and ASP.NET on one server, but
becomes a management nightmare (managing the ACLs grows exponentially) as
you add servers.
Suppose you now want to access those session variables in a JSP application.
Do you look in the ASP app or the ASP.NET one? Since there is no
SetSessionVar to match GetSessionVar, there is no common store; therefore,
this architecture does not allow us to determine which value is freshest.
The DB approach is far more elegant, IMO.
--
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.
| |
| Jon Paal [MSMD] 2007-07-26, 6:56 pm |
| I don't want to argue with you.
The cookie solution presumes the existing ASP solution is not going to have to be rewritten to store information into a database and
allows it to be the primary source of the session value.
This will keep the classic ASP solution as the primary and any other apps like JSP would refer back to Classic ASP as the source
also.
I like the cookie solution....
| |
| Jon Paal [MSMD] 2007-07-26, 6:56 pm |
| Yes, the presumption is the old Classic ASP is the basis for the source and new code would derive from it.
Again , I don't want to start a debate on preferences. But if someone is mixing ASP, ASP.net, JSP, etc., I think it might be time to
step back and revisit where things are going...
I like the cookie solution ...
| |
| Dave Anderson 2007-07-26, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
> ...if someone is mixing ASP, ASP.net, JSP, etc., I think it might be
> time to step back and revisit where things are going...
Mixing ASP and ASP.NET is no surprise. Anyone with a large base of ASP
applications may have to do this at some point.
As for other technologies (like JSP), many of us work for companies that
feel compelled to buy industry-specific off-the-shelf software that must be
integrated with the homegrown stuff (not to mention portals, ERP and content
management systems).
--
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.
| |
| Dave Anderson 2007-07-27, 6:56 pm |
| "Jon Paal [MSMD]" wrote:
> The cookie solution presumes the existing ASP solution is not going
> to have to be rewritten to store information into a database and allows it
> to be the primary source of the session value.
>
> This will keep the classic ASP solution as the primary and any other
> apps like JSP would refer back to Classic ASP as the source also.
I agree with all of this, provided you do the extra work needed to SET
values in the classic ASP sessions (and also that the classic ASP app is not
load-balanced).
--
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.
| |
| Bookham Measures 2007-08-17, 6:56 pm |
| (bottom posted)
"Dave Anderson" <NPQRWPDWZGSP@spammotel.com> wrote in message
news:%23Rm127UzHHA.3916@TK2MSFTNGP02.phx.gbl...
> "Bookham Measures" wrote:
>
> I wholeheartedly endorse this decision. It's a great way to share session
> information between multiple web technologies (like ASP and ASP.NET), as
> well as across servers.
>
> We use two tables: One is common session information (session ID (PK),
> session expiration, user ID (optional), and demographics (user agent, IP
> address, etc.). The other contains the variables, with session ID and
> name-value pairs.
>
> We have been using this for more than three years, and have one regret --
> this design does not allow scope limitation. Our next version will have
> optional domain & path restrictions, much like cookies have.
>
>
> --
> 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.
Hello
I'm thinking of using a GUID generated by SQL Server as the Session ID and
just cookie-ing that to the browser. This should eliminate the chances of
anyone being able to guess a sequential number.
What would be the best way to protect the Session ID cookie from being
manipulated/intercepted?
I am not able to switch the whole site to SSL or supply a new checksum value
over all the querystrings/links, this information could be readable anyway.
I can implement a timeout based on the time of the last request etc. but I'm
wondering if there's anything slightly cleverer. I could probably do
something with the IP address to ensure the request, albeit it possibly
malicious, is at least originating from the same IP as that when the session
was started. This would limit the attack to the same proxy server or
corporate network perhaps.
I note in Classic ASP, that even the cookie name has been subject to some
encoding, E.G. ASPSESSIONIDASSSQCBC=JFEMNMICCBCALFJPCJO
FJHFK. What is to
be gained by this and isn't it slightly inefficient to have to examine the
whole cookies collection to extract one where:
For Each strKey In Request.Cookies
If Left(strKey, 12) = "ASPSESSIONID" Then
stKeyRemain = Mid(strKey, 12)
Exit For
End If
Next
How could/does this extra bit help us or secure the cookie?
I have been reading about the various session management methods available
in ASP.NET, but none of them explain how this kind of interception is dealt
with. It's so easy now with some of the plugins available on FireFox to
manipulate almost anything.
Many thanks in advance.
David
|
|
|
|
|