Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.
Match ASP.NET Profile ID with page request
I understand that the web is stateless, and that state can be maintained between pages using Sessions, which is always on the server and per client. It knows which browser (request) the generated id belongs to because of the use of cookies or url embedding it uses. I understand that the url embedding can be unsafe if encryption is not used with it.
I have read that the anonymous ASP.NET Profile method for maintaining state uses cookies to identify a request coming in from a browser.
So how is an authenticated Profile user's identity matched with each request? Is a cookie or url embedding method used here as well?
I have read that the anonymous ASP.NET Profile method for maintaining state uses cookies to identify a request coming in from a browser.
So how is an authenticated Profile user's identity matched with each request? Is a cookie or url embedding method used here as well?
Who is Participating?
A session can exist without cookies. Cookies enable a stateless experience so certain things like user preferences can be stored and retrieved between sessions. Cookies also allow you to prepopulate things like username, so visitors only have to type a password.
"So how is an authenticated Profile user's identity matched with each request?"
An authenticated user would typically be bound to a session. That is, a user authenticates, and the fact that the user authenticated is remembered and persists for the duration of the session. Closing the browser (or logging out) kills the session and destroys the authentication. While it would be possible to store both a username and password in a cookie, then read that information back whenever a user visited a web site, it's a bad idea for obvious reasons.
I'm not sure if I've answered your question or not. Feel free to steer the conversation if I haven't.
"So how is an authenticated Profile user's identity matched with each request?"
An authenticated user would typically be bound to a session. That is, a user authenticates, and the fact that the user authenticated is remembered and persists for the duration of the session. Closing the browser (or logging out) kills the session and destroys the authentication. While it would be possible to store both a username and password in a cookie, then read that information back whenever a user visited a web site, it's a bad idea for obvious reasons.
I'm not sure if I've answered your question or not. Feel free to steer the conversation if I haven't.
I have an understanding of all of what you mention, but am not sure how Profile State management works when it comes to identifying each page request. The focus is on each page request with respect to Profile state management and how they do it.
Most articles I've come across seem to imply that Profile Properties somehow magically know which browser has made the request, so they tend to skip the explanation of how this actually happens.
Each web page is independent, so the only way Profile Properties know which browser sent any page is by using a mechanism like cookies, url embedding, or some form of browser caching or similar.
Simply put, how does the Profile state management system know which page request belongs to its unique ID?
With Session State they use cookies and url embedding, what is used with Profile State?
Most articles I've come across seem to imply that Profile Properties somehow magically know which browser has made the request, so they tend to skip the explanation of how this actually happens.
Each web page is independent, so the only way Profile Properties know which browser sent any page is by using a mechanism like cookies, url embedding, or some form of browser caching or similar.
Simply put, how does the Profile state management system know which page request belongs to its unique ID?
With Session State they use cookies and url embedding, what is used with Profile State?
ASP.Net Profiles are stored in a database. They're associated with a session when a user authenticates.
A session exists between a client and the server. The client is usually (but not always) a browser. You presume incorrectly when you think "cookies, url embedding, or some form of browser caching" is required. The session is maintained between the client and the server, it has a unique ID and that ID is sent by the client whenever it transacts with the browser.
"With Session State they use cookies and url embedding..."
Again, this assertion is incorrect. Most IIS session states are maintained "in-process". That is, they exist in memory as long as the session persists. Disconnecting the client (closing the browser), logging out, or just letting the client sit idle for 20 minutes or so is enough to flush the session information from memory, requiring the client to start a new session.
So, "Profile State" is different from "Session State". Furthermore, Profile information can be stored as part of the Session State. Requests from the client are recognized by the server as being part of the same Session, so the Profile information can follow those requests around as long as the Session persists.
A session exists between a client and the server. The client is usually (but not always) a browser. You presume incorrectly when you think "cookies, url embedding, or some form of browser caching" is required. The session is maintained between the client and the server, it has a unique ID and that ID is sent by the client whenever it transacts with the browser.
"With Session State they use cookies and url embedding..."
Again, this assertion is incorrect. Most IIS session states are maintained "in-process". That is, they exist in memory as long as the session persists. Disconnecting the client (closing the browser), logging out, or just letting the client sit idle for 20 minutes or so is enough to flush the session information from memory, requiring the client to start a new session.
So, "Profile State" is different from "Session State". Furthermore, Profile information can be stored as part of the Session State. Requests from the client are recognized by the server as being part of the same Session, so the Profile information can follow those requests around as long as the Session persists.
So does Profile State management depend on Session State, or are you referring to different things when you mention "session" and "Session State".
Is it correct to say that a session's data is server-side only? If so, how does it communicate with a browser so it can connect the correct session data with the correct browser?
Is it correct to say that a session's data is server-side only? If so, how does it communicate with a browser so it can connect the correct session data with the correct browser?
When a client makes its initial request to the server, the server generates a Session ID and passes that back to the client. The client sends the Session ID with every subsequent request so the server knows which session/client is making the request.
Many articles call this an in-memory cookie that is deleted when the browser closes, so I think I was referring to this when I mentioned cookie. I probably should have called it in-memory cookies, however, as far as I know, url embedding is used in cookieless sessions, but again, perhaps my terminology is incorrect.
Yes, for the purpose of this discussion.This tells me that you don't really believe that Sessions are always used with Profile State, or am I getting it wrong?
"This tells me that you don't really believe that Sessions are always used with Profile State, or am I getting it wrong?"
Profile information is loaded into a Session when requested so the Profile information can follow the client's requests - which is what you seem to be asking about. Technically, Profile information can exist without a Session (just by being in a database - but the information is not useful there). I'm not trying to be coy, just precise.
Sessions do not equal cookies, regardless of what you may have read. Here's some information on Sessions and IIS:
http://msdn.microsoft.com/en-us/library/ms178586(v=vs.80).aspx
Profile information is loaded into a Session when requested so the Profile information can follow the client's requests - which is what you seem to be asking about. Technically, Profile information can exist without a Session (just by being in a database - but the information is not useful there). I'm not trying to be coy, just precise.
Sessions do not equal cookies, regardless of what you may have read. Here's some information on Sessions and IIS:
http://msdn.microsoft.com/en-us/library/ms178586(v=vs.80).aspx
Yes, I can see now that technically Profile data don't need Sessions, and Sessions don't always need cookies, but it is the web request / response process and the stateless nature of the web that requires a means of always knowing the logged on status of a specific web page request across web requests.
So, just to clarify your comment,
So, just to clarify your comment,
the server generates a Session ID and passes that back to the client, where in the client is the Session ID stored?
"...Sessions don't always need cookies..."
Sessions never need cookies.
"...but it is the web request / response process and the stateless nature of the web that requires a means of always knowing the logged on status of a specific web page request across web requests."
That's what Sessions are for.
N.b. One doesn't have to use ASP.Net Profiles to authenticate visitors. On my own ASP.Net web site, I have my own process wherein I set a Session variable to "true" when a visitor successfully authenticates. I check for this Session variable to be "true" on pages that should only be accessed by authenticated users. If the Session variable isn't "true", I send the visitor to the login page, with a parameter that returns them to the page they were trying to access in the first place.
So, while ASP.Net Profiles are an easy way to wire up authentication/customizati
"...where in the client is the Session ID stored?"
In the memory used by the browser somewhere.
Sessions never need cookies.
"...but it is the web request / response process and the stateless nature of the web that requires a means of always knowing the logged on status of a specific web page request across web requests."
That's what Sessions are for.
N.b. One doesn't have to use ASP.Net Profiles to authenticate visitors. On my own ASP.Net web site, I have my own process wherein I set a Session variable to "true" when a visitor successfully authenticates. I check for this Session variable to be "true" on pages that should only be accessed by authenticated users. If the Session variable isn't "true", I send the visitor to the login page, with a parameter that returns them to the page they were trying to access in the first place.
So, while ASP.Net Profiles are an easy way to wire up authentication/customizati
"...where in the client is the Session ID stored?"
In the memory used by the browser somewhere.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month7 days, 21 hours left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
Yes, for the purpose of this discussion. When I log in to an ASP.Net web site that uses Profiles, my Profile is stored in the Session and follows me around as long as the Session persists.
"...are you referring to different things when you mention 'session' and 'Session State'."
No, not for the purpose of this discussion.
"Is it correct to say that a session's data is server-side only?"
Yes, for the purpose of this discussion.
"If so, how does it communicate with a browser so it can connect the correct session data with the correct browser?"
When a client makes its initial request to the server, the server generates a Session ID and passes that back to the client. The client sends the Session ID with every subsequent request so the server knows which session/client is making the request.