I use session objects in my web application which are traced by ASP.NET session cookie internally as we all know. So access to that cookie is essential to have access to session objects. I want my asp.net application work under http:// and http://www or any subdomain (domain is unknown to me at development time).
Can't be done. The session cookie only works for 1 domain and 1 domain only.
You could, however, write your own session management system and maybe accomplish shared session that way. I still don't think you'd be able re-use the cookie because the browser won't even send it in the first place.
After some more thought I've decided that I'm not sure. :) Perhaps if both subdomains map to the same ASP.NET application you could get share session to work. All you'd have to do is set your cookies as such:
<httpCookies domain=".maindomain.com">
If the different subdomians don't map to the same app, I think you'd definitely have to write your own session management.
Clearly, at this point you should take everything I've written with a grain of salt. I'm only leaving my answer up for you to get some ideas and so that people may comment on the correctness of it.
Why don't you leave domain field empty? That way you won't bind your cookies to some specific domain and will be able to play well whatever the domain of your site will be.
Related
I originally used static variables to store some user information when a user is browsing my site. I had issues where occasionally a user would navigate somewhere and see a different users name on the page. I switched to using session variables to solve this, but the same problem occurred. I then thought making the session variable names unique in some way would solve the problem, e.g. instead of
Session["userId"]
I changed all session variables to append the unique username of the user when they are created and referenced, so they are:
Session["userId" + Context.Identity.User.Name.ToString()]
So far I've had no reports of the issue, but is this actually going to work? Is there a simple way to protect sessions so the variables don't leak between users? I'm confident with ASP.NET code (webforms specifically) but have only encountered the session issue as more users use the site. I don't have much control over IIS settings as the site is built via AWS Elastic Beanstalk, so it's mostly default IIS settings.
This should work fine, but I suggest storing username or user profile information in cookies or local storage since as you mentioned when lot of users logged in it maintains session for them on server memory(I believe session is in-memory by default not in-proc or redis). This is not scalable as if millions of user logged in or you create load test server considerable memory will be taken by session management. Few hundred users however is not much overhead.
You can store information at user browser using sessionStorage like:
Setting value
sessionStorage.setItem("user_name", "test");
Getting Value
var userName = sessionStorage.getItem("user_name");
It can store javascript object or json too.
Cookies are old way to store info at user end :
Creating cookie
document.userCookie = "username=John Doe";
reading cookie
document.userCookie //"username=John Doe"
Forms authentication also provide encrypted & secured cookies which is maintained with session which is also good if user profile information is sensitive data.
Sorry, I can't write comments for your question, but:
Same issue happed to Java developer with AWS Elastic Beanstalk:
https://forums.aws.amazon.com/thread.jspa?threadID=84027
First, I suggest you try to set no-cache for your HttpResponse (temporary solution), than
I suggest you try to play with your IIS proxy settings.
If it didn't help (and you're using load balancer) - refuse from using inproc settings like in this topic:
User on wrong session
PS. You really don't have to make session variable names different - Session uniqueness is guaranteed by ASP.NET setting different Session_ID for each session.
Is it possible to share Session state between web applications on separate servers? One of the web sites is using session state to maintain user credentials/info session state, the other is using forms authentication to maintain this information. Without modifications to the website using session storage, is it possible for the website using forms auth to read/access the session state on the other server? If not, which I assume is the answer, would it be possible if they ran on the same server? (i.e. the same app pool)?
Note: Both applications are under the same domain name (one of them will be a sub-domain)
As a note, the reason this is being asked is because a client is requesting a "single sign-on" approach between two websites. We're using forms authentication and the other site (which we cannot modify at this moment) is maintaining credentials/logon information in session
ASP.NET 4
IIS 7.5
Assuming the latter, you could try something like this:
first, make sure all the appliations are running in the same domain. If not, all bets are off. I don't know if there's a simple way to configure the domain property of the session cookie yet, so you may have to do it yourself, by setting the cookie domain property to the domain:
Response.Cookies["ASP.NET_SessionId"].Domain = ".mydomain.com";
you'll need to make sure that each application is configured to use either a common state server, or a db-backed session.
please follow the link : How to share session state across subdomains
I have an application with different sections. Each section is accessed through a domain. Example: www.section1.com, www.section2.com, www.section3.com. I need to preserve the session when the user navigates from one to another URL. The application is the same in IIS. How to accomplish that?
You will need to pass on the session-cookie, and re-set that cookie on the new domain. That will make the session live over several domains (assuming you use the same app).
Example:
Link from section1.com:
<a href="http://www.section2.com/?s=askdjh3k4jh234kjh">
then, OnSessionStart (or OnRequestStart) check for query-parameter s and attach session to it. Meaning, just manually set cookie ASP.NET_SESSIONID to the value you pass on.
This has severe security-implications, so don't allow this unless you know what you're doing. another solution might be to store something into a common backend (database?) and pass around the user with a token that represents the actual session (and set the cookie based on that token), that you generate on a middle-page when navigating away from section1.com -> transferusertonewdomain.aspx -> section2.com/?token=randomTokenThatMatchSessionInDatabase
That would prevent that anyone could hijack a session by jsut knowing the value of the cookie. However, that is possible never the less if you're somewhat familiar with a computer anyway.
If you have multiple domains (and not just subdomains, which are easier), you're going to have more complications doing this than you'd like, because you can't share cookies across different domains.
The usual workaround is to embed a link an image on the other domains that are served by an asp.net page (or HttpHandler if you like). That page should contain a querystring with a unique token and a hashed version of that data appended with some shared secret. Then, that page will set a cookie on the response appropriate to for that domain to associate itself with appropriate data. It will serve typically a 1x1 transparent image as the response. Usually you only want to do this upon login to one of the sites.
Unless you do some customizations, session is specific to an application regardless of session mode you are using. Here's an article that talks about how to customize SQL session so that you can use session across multiple applications.
You should start by change the sessionState from being "InProc" to either StateServer or SqlServer, ensure that the MachineKeys are identical across all sites (domains and servers), and then set up the relevant backend systems to capture the state information.
More information can be found on:
Session-State Modes
ASP.NET State Management Overview
You could use a cookie to pass it, still researching to find out how. I will repost.
** EDIT
There is another Stack Overflow question, see if it helps, 315132
It basically asks
I need to share SSO information
between two different domains with a
cookie, can this be done in PHP and
how?
the answer given was
On both domains, place an image or
other web element that is pulled from
the other domain. Use the URL to
notify the other domain that user X is
on domain A, and let domain B
associate that user ID with that user
on their system.
It's a little complex to carry out
correctly, but if you think it through
it'll work out very well.
Vinko points out in a comment
(thanks!) that I shouldn't take it for
granted that you understand the
security risks involved. If this
information is of any value to anyone,
then you should make sure you use
proper encryption, authentication, etc
to avoid releasing sensitive
information and to avoid various
attacks (replay, man in the middle,
etc). This shouldn't be too onerous
since you control both websites and
you can select a secure secret key for
both, since the communication is only
going between the two servers via this
special URL. Keep it in mind though.
The user is Adam Davis.
We have extended a legacy app, however the existing login and user management mechanism doesnt seem to work with the new module.
Our module keeps causing the user to be logged out, when they navigate back to the existing application.
We've removed all pages which might force the session to be expired.
We have no code related to user sessions and logins
We have no code that logs out the user.
Could use Database or Memcache perhaps but both are going to be messy if you can't use SessionID or similar as a key I suppose.
You are not telling by wich mechanism the server should know which user is logged on ? What are you currently using: javascript, asp pages ?
If you should be using cookies, please make sure that the domain name you use in your cookie writing and cookie writing code (especially when you are mixing javascript and asp code) is written the same (so case sensitive). If not your code might be reading another value than the one written.
I know I have been searching for a problem a long time before I found out that I wrote the cookie to domain Edelcom.be and was reading if from edelcom.be.
You should be able to use Cookies as this doesn't depend on sessions staying alive. Cookies can persist as long as you want them to - you just need to set the "expires" value.
It sounds like you are actually wanting to get rid of session variables for logins but this should not mean you have to also ditch cookies.
We have a web application running on ASP.NET 3.5. It is viewed by the world as one URL but in reality there are multiple IIS boxes hosting the application controlled by a load balancer.
My problem is that it is a sensitive application with strict security controls around it, and that post authentication if you open another browser to the same application and log in as someone else, the second login overwrites the first logins' session id value in the cookie, and then the first window crashes.
Any idea how I can get around this?
The session ID is placed in the cookie. If another browser window is opened and starts a second session the ID in the cookie will be replaced.
Also, logins should not be controlled via the session cookie. There is a Forms Authentication cookie for that purpose which is more secure as I recall.
Most web applications only allow one session per PC. Try logging into Yahoo Mail, Amazon or Ebay twice on the same machine and you will find the same problem. So ASP.NET is pretty much designed around the idea that there is one login per PC. Although, if you have multiple browsers installed on a machine, you can generally log into apps more than once because each browser keeps its own cookie collection.
edit: You might want to try cookieless sessions, in theory they might allow multiple sessions per PC, although I haven't tried it. But cookieless sessions come with plenty of problems and limitations of their own.
In short, there may be some hacky way to do what you want to do, but it will probably be fiddly and cause other problems elsewhere, because what you are asking for goes against the grain of ASP.NET's core design.