You are probably backing up your data—but how and where? Ransomware is on the rise and there are variants that specifically target backups. Read on to discover why off-site is the way to go.
Course Of The Month
2 days, 4 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Match ASP.NET Profile ID with page request
Posted on 2012-12-26
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?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
6-
6
12 Comments
Active today
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?
Active today
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?
Active today
"So does Profile State management depend on Session State..."
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.
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.
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?
Active today
"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?
Active today
"...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.
Featured Post
We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
This article aims to explain the working of CircularLogArchiver. This tool was designed to solve the buildup of log file in cases where systems do not support circular logging or where circular logging is not enabled
This article will inform Clients about common and important expectations from the freelancers (Experts) who are looking at your Gig.
This tutorial demonstrates how to identify and create boundary or building outlines in Google Maps. In this example, I outline the boundaries of an enclosed skatepark within a community park.
Login to your Google Account, then Google for "Google M…
The viewer will learn how to dynamically set the form action using jQuery.
Suggested Courses
Course of the Month2 days, 4 hours left to enroll
717 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.