We are using Asp.net Session in our application for state management. By default, In-proc mode is being used. But now, we have to look for an alternative as we have been asked to remove Session from our application by our client due to performance issue.
One of the way is to keep everything at Client side say in hidden field on Postback. It's not a good approach for sure.
Is there any other way of doing it? Im sure there would be an alternative.
PS: Please don't suggest Querystring.
Thanks,
Sumit
Something close to that is HttpContext.Current.Items but has a shorter life span
Items collections of HttpContext is and IDictionary key-value
collections and that are shared across a single HTTPRequest. Yes,
HttpContext.Current.Items valid for a single HTTPRequest. Once
after processing, server information is sent back to the browser,
the variables that were set in the Items[] collection will lost. Where
as for Session Variable, information valid for multiple request as
this is user specific. The session variable only expires either on
Session Time Out or explicitly clear the values.
More from these articles
When we can use HttpContext.Current.Items to stores data in ASP.NET
Related
Let's say a user is banned in a website, but his session is still active. What's the best way of preventing him from performing an action that a banned user is not allowed to do?
The two plausible solutions I came up with are
making an additional checking previous to every "major" action,
like making a post in the forum, sending a private message, etc. to make sure
he is not banned (checking with the database)
destroying his session
Now, the latter solution could be done by setting an expiration for the cookie, but this would be bothersome for the rest of the users as they would have to log in again.
Other option would be setting a timeout in the session in which the scripts checks if he's banned with the database and then destroying his session if he is, but this seems like a bit too much.
What's the best way to deal with this?
If I understand what you mean by setting an expiration for the setting cookie, I would recommend against it. You want the control to be on the server side - don't trust your clients; they can easily prevent a cookie on their side from being destroyed.
Hopefully, whatever framework you're using has a way to delete the server-side data associated with a user's session, instead, invalidating the client's session id.
If your application is object oriented, you could do a check in your constructor, if the user is banned, and if he is, unset his session/call the log out function.
Is it a bad idea to put sensitive information (user ID's, connection strings, things I might not want visible to other user's) in the ViewBag? Can an external user get to that info in any way?
My thought is no, they can not get to it (I have tried, not that I am in LulzSec) but I was curious on other people's thoughts.
Thanks in Advance!
ViewBag is session based and it only the CURRENT request based and as such has the same constraints as the session with the added benefit that it is deleted at the end of that request, so no - this is not accessible. Even if someone could steal your session id and hijack the session, viewdata would be gone.
TempData is another story and session hijacking would allow a user to hijack another session - hence tempdata but a user still wouldnt be able to see that by default unless you have this information emitted into trace info. So basically if I could steal your session, whatever code you have on the next request would be executing for me, and not for the user its 'waiting' for on the next request. But - they still can't enumerate it and access it themselves.
Since the ViewBag is only used for server side processing, adding dynamic functionality to mimic a more Ruby- or Python-esque approach, I don't think you need to worry more about security than with everything else being stored and used on your server.
Ok, I'm new to web development, so I might be getting some of these terms wrong. I apologize in advance.
I am having trouble understanding the different elements of authentication. Every method seems to be advised against by someone, though not always with clear reasons. I am building a web app for a company that will have access to a database, so I would like to make sure it is secure.
So the there are three places I have seen commonly used to store information.
FormsAuthentication.SetAuthCookie(). This stores a session cookie that will exprire with the browser, and nothing sensitive is on the client. However, it can only store one value. This stackoverflow answer shows a method of storing multiple values here, but the guy who gives it says not to use it, though not why.
FormsAuthenticationTicket. I don't know where this information is stored, but it allows for a simple method of storing multiple values. Securing it, according to the documentation requires calling Encrpty() to store, and decrypt() to retrieve. This seems wasteful, but what do I know.
Session["SomeRef"] = new CustomObject(). The second answer in this question explains how to do this, but a comment to it calls it dangerous because it can be stolen. This looks like the best method to me, because the information is still stored on the server, and can store multiple values.
I cannot find any comparisons for these methods, or good explanations on the "best practice" way of storing multiple pieces of information after authenticating a user. The information is just the User's name and their userId.
Here is some further clarification to help you decide.
SetAuthCookie can be implemented in a way to store multiple values. In practice, however, you usually can't store enough to avoid a database lookup. It's best to store the user name (unique identifier) and load more information during the request. As your question suggests, you shouldn't store sensitive information on it. You should assume that all information sent in a cookie can be decrypted and read and you should take precautions that that information can't be used maliciously. All session cookies can be stolen and I'll explain why in a moment.
FormsAuthenticationTicket is the same API as SetAuthCookie but at a lower level in the Framework. With SetAuthCookie, Encrypt() and Decrypt() should be happening anyway (it's the default configuration.) It's not wasteful but use method 1 instead because it's easier.
Session has some limitations. Notably, by default it's process-dependent. That means that when the server restarts or more than one web server is involved, your session is lost and you have to authenticate again. It is the easiest to use and fastest when using the default memory session storage (InProc). You can use sql storage or a dedicated session server to overcome the process-dependency.
All three methods are considered dangerous for the same reason all cookie-based authentication systems are dangerous: because the cookie's value can be sniffed over wireless and reused to take over a session. This is known as sidejacking and it also applies to scenarios 1 and 2. The way to prevent this is to implement HTTPS. Then, the cookie transimission (and everything else) is encrypted at the network level and can't be stolen.
TLDR; Use SetAuthCookie and HTTPS
NOTE this answer has been edited several times for clarity.
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.
I'm creating josi, a web framework for node.js. And I'd like to add session storage. What would be the best way to implement this? I'm assuming it probably has to be cookie based, but I'm interested in knowing if any other frameworks have a different approach.
I had a look at josi a few days ago. Very nice work!
Other than cookie based, you could use infamous session tokens (e.g. JSESSIONID, PHPSESSID and ASPSESSIONID) and put them in hidden forms or the URL query string.
Cookies are really the best option. They work perfectly for the job.
You always need to reference the server session somehow, cookies are the de-facto standard for this sort of stuff.
How the session is stored on the server side is usually up to you... I really like PHP's approach with session_start(); which does all the session storage and cookies setting for you.
PHP for example stores the session data in a file, making it cross-platform (all platform's have disk storage APIs). Other session mechanisms use a relational-database like MySQL, but that's not really cross-platform unless you want to target those type of users.