Context is:
I need to send the SessionID (will be encripted) to an app, then the app saves the session ID and on the next query the app sends me back the SessionID so I can use the stored Session variables.
So HttpContext.Current.Session.SessionID gives me the current SessionID.
But... how do I recover the Session based on the SessionID?
P.S. I am aware that this is a duplicate of this unanswered question: How do I get a session by SessionID in C# so as a plus if there is no way of retrieving the Session from the SessionID I would ask if there is another way to achieve that.
As far as I am aware, there is no public API available to load a session based on session ID (I have asked the question here, as well). You can hack it using reflection, but that will only work if your site is in a full trust environment and you are okay with the performance implications of using reflection.
As was pointed out in the comments, session state is normally driven by a cookie (by default named "ASP.NET_SessionId"). If you pass the cookie from the request of your "app" (which I am assuming you mean a remote application) to the server, you can then access session state simply by calling HttpContext.Current.Session on the server side. You just need to add the cookie to the headers of the request from the application for it to work.
However, I don't think session state is the persistence mechanism you are after for your scenario. Rather than dealing with cookies, it would make more sense to store your state in a persistent format such as a file or a database and use a GUID or other unique identifier to access it based on an ID passed in through the URL.
As Alexi pointed out, another possibility would be to build your own session state provider that you put your own back door into in order to access the raw data, but it will take quite a bit of work to pull that off.
Related
First of all, I'm new to MVC, but I managed to create a simple custom login using Entity Framework, MVC 5 and C#. ( I do not want to use Identity because the idea is to get to know the functions behind it).
I'm currently doing this with Session Variables, so when the user exist in the DB, I store the info like Role, Name, etc. in Session Variables, but when the user closes the browser or I restart the app the session is lost so the user has to login again, how can I prevent that from happening and keep the user logged like Identity does?
There seems to be some confusion about how authentication and sessions actually work here.
First, sessions utilize cookies. That's how they work. A cookie is set with the session identifier so that the server can retrieve the appropriate session with each subsequent request. The only alternative is what's referred to as "cookie-less sessions", where the session identifier is passed around as a query string parameter. However, these are generally discouraged because inevitably the URL leaks and its far too easy to hijack user sessions this way.
Second, sessions on the server are not the same thing as a browser "session". The server-side session does not expire when you close your browser. That's just patently false. You can however, have the cookie containing the session identifier be set as a "session cookie", which causes the cookie itself to expire when the browser session ends. The server session still exists, only without the cookie, there's no way to look it up. However, you can just as easily have the cookie expire after a period of days or weeks. The fact that it's a cookie used to maintain a session doesn't necessitate that it be a "session cookie".
Third, there's different mechanisms of session storage. The default, because it requires no configuration, is what's called "in-proc". That means the session data is stored in memory by the web server process. When the web server process is terminated, its memory block is freed, along with your session data. Persistent sessions require persistent storage, meaning something like a database.
Long and short, there's nothing wrong with what you're doing, you just don't have your sessions configured properly. Refer to the MSDN docs on the <sessionState> Web.config element. You'll need to add something similar to:
<sessionState mode="SQLServer"
cookieless="false"
timeout="3600"
sqlConnectionString="[Connection String Here]" />
Today I got that question...
Is that a big problem when we store password like a plain text in Session of the ASP .NET MVC?
I know that Session also uses a cookie, but the cookie itself only contains a key. The server uses the key to obtain a dictionary of key/value pairs unique to that session, which stay on the server (or get serialized to the DB, depending on how it's configured).
So is it possible that some hacker can get it somehow?
I need clear answer about it. If it is possible I need some explanation
how it could be done. I need it to see possible risky of that approach.
Thank you!
I presume that the password is being stored within session because the application uses it for something. A hacker is not likely to be able to read the password (without owning the web server) but it is possible to attack the session and take it over then use the password via the application.
Two attacks I can think of immediately:
Session fixation attack. Hacker starts his own session with your app, notes the session ID, then prepares a specially crafted email which when opened will cause a user to access your site using that session ID. When the user logs on, the hacker will have access to the same session because they have the ID in common.
Brute force. The session ID is a 120-bit number. A hacker can continuously poll your site with random session IDs until he finds one that works. It's difficult to guard against this form of attack because ASP does not distinguish between a falsified session ID and a real session ID that has expired.
It is absolutely insecure. There are several methods how attacker can steal user session, e.g. Session fixation, Session sidejacking, Cross-site scripting. You can start your research from Session hijacking article.
I am trying to implement a web application with Caching features.The reason I need caching is for is that we have an application which lets users access online courses. Now, Once the user logs in I validate him against our database. Once validated I want to store the user ID and course ID in cache for 20 mins so that if he requests it again I can retrieve values from cache foe both user id and course ID and if valid provide him access
For some reasons I can't use Session variables in this application so they are not an option.
Now, the caching code in my application is inside a HTTP Handler(.ashx file). Now I tried calling the cache object like you do for a aspx page but I could not, probably because it's a handler and not a webpage.
So,
Cache.Insert("Id", 123);
will not work in Handler. So then I tried HTTPRuntime.cache. But after doing some research I found out the HTTPRuntime.cache is common to the whole application. I don't completely understand "Whole application". Does it mean that it is shared by all the users on different computers accessing our applications? or does it mean it's shared by all the users on one computer accessing our application. Because if it is the latter I am OK with it.
So is HTTPRuntime.cache a good way to cache data for one browser(or one computer) or is there a different and better way to implement Browser caching to store data?
Cache is stored in web server memory.
You should understand the differences between Viewstate, Cache and Session
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.
I currently have a website and upon registration to the website i generate each member a unique GUID. Upon the user logging in to the website i check the credentials and store the guid in session if successful, in order to show the user there profile / how many post have been made etc i run my queries to the database passing the users session GUID to fetch data related to them.
Can anyone kindly confirm a better approach for this ?
Have a look at the membership features in ASP.Net: http://msdn.microsoft.com/en-us/library/ms998347.aspx
This is basically how most authentication/authorization systems work. Some things you may want to keep in mind:
Don't reinvent the wheel if you don't need to - as Max pointed out, ASP.NET has a built-in auth provider that is fairly feature-rich and can be extended as well.
I would avoid storing anything in Session unless you have to. It is easy to get lazy with Session, and it is also potentially volatile - if you bounce the service, anything in Session is gone.
If you store a cookie on the client to handle this, ensure it is salted and encrypted.