I am using ASP.net for developing an intranet website. I need to hold the userid across all postbacks for all the pages in the website. Is it advisable to hold those information in Session or somether way is available.
FormsAuthentication is also capable of holding a custom userid, and solves a lot of things for you like setting the cookie, login page redirection etc.
You can set the userid using the RedirectFromLoginPage method and then use the FormsAuthentication_OnAuthenticate event to find and set the Page.User property, to access all the other logic you need.
If using Forms Authentication, then the username will be available as:
Page.User.Identity.Username
If you need to hold another piece of information alongisde this, then use Session.
PS. I recommend using a class to wrap your session variables for strong-typedness and potential default values.
The most common ways of doing this are using either the ASP.NET Session Object or using cookies.
Either way will work well, but if you wish for their user information to persist even after the session has timed out (such as the closing of a browser window), then you would want to look into cookies. Session information will be disposed upon closing of a browser, or the activity timeout has been reached.
Related
I am creating a new asp.net MVC 5 application. Authentication is handled by a third party using smart cards. Once a user is authenticated by the third party, I am sent the user's unique ID (inside the http header) which I match up against my database in order to find relevant information about said user (roles, display name, etc.).
Currently, on every page request, the sent user ID is compared against the database, and checks are performed to ensure the user has the proper permissions to view the requested page. While this works, it sure seems like a bunch of needless database hits when all the user information could just be stored in a cookie.
If I was using Individual User Accounts for authentication, what I am looking to do would simply be built in using Identity and OWIN. But since I am not handling the authentication, but merely the authorization, is there a way to use all the nice features of Identity and OWIN (claims and cookies specifically)? If not, how might one go about this?
Also, of particular interest to me is when a role is added or removed. Using OWIN with Individual User Accounts, updating the cookie is as simple as logging the user out, and then back in immediately in the background. That functionality would also be desired for any solution presented.
Any insight would be extremely helpful. Thanks for reading!
You could do what you're asking by directly storing values in a custom cookie, but for your purposes it sounds to me like you might be more interested in utilizing sessions to track that info. This will keep all of your actual data stored server-side, which is more secure as it isn't vulnerable to cookie modification and it allows you more freedom to control the state (for your role example, you wouldn't have to "update" the cookie at all, just update the session variable on the server side to add or remove the role as needed).
Figured it out. Found a great article that really helped:
http://www.khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown-part-deux
I am working on a small web application right now and part of the requirements is to allow the user to pick how their session will be managed: with either cookies or HttpSessionState. I have researched how to use cookies (http://www.codeproject.com/Articles/31914/Beginner-s-Guide-To-ASP-NET-Cookies) and Sessions (http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx). I will be using non-persistent cookies.
The application will collect some data about the user (name, age, school) and take this session data and display messages on another page depending on the data that the user entered.
The thing I am having problems with is how to deal with how the user will pick the management. That information is also part of the session! The selection will be checked on every page on the web application.
I have researched globals (http://www.dotnetperls.com/global-variables-aspnet) but that is not a good method because it can be shared among different users which is not what I want! Correct me if I am wrong. How can I store this data temporarily through the session without actually using a session or a cookie?
Is it even possible to do this with cookies and sessions being mutually exclusive?
At the end of the day, you should save it somewhere. This option if it is not persistent, as it may be asked/changed by every time user visits the web site, the easiest way is to save it in a hidden html field. As user submits the forms, the value will be passed to the next page if you are using html forms. Or you can retrieve the value and send it manually in asp.net (e.g. Transfer).
You may use ViewState (not recommended) as well. If the information should be persister for future, try using User Profiles in ASP.net and save it as a custom field in database. This one is really cumbersome.
I have a user control that only displays customer information on each .aspx page in my application. That user controls contains public properties for customer information those are set from .aspx page (say page1.aspx) OnLoad event and displays information in that user control. Now from this page1.aspx, redirects to page2.aspx but couldn't able to display information in page2.aspx usercontrol (the values are lost after postback). I could maintain user control's properties state by using session in each proprty of control and can access in all the pages, but sessions would be expensive ways to do that. Please give me another better solution about this, so that i can maintain user controls properties value across postbacks.
Thanks in advance...
The information is not lost in PostBack as the Page2.aspx gets a seperate GET request after doing a redirection from Page1.aspx
There are below ways by which you can do state management
Session State
Application state
View State
Cookies
Query string
HTML Web storage
Session state is what seems to be the logical choice for your scenario, As application state would affect the data for all the users who are logged in. Viewstate will be lost once we do a Redirection. For cookies there would be problems with size limit and you need to clear the data stored in cookies. Also, you should be encrypting the data stored there. Query strings are easy to be tampered & is not reliable. HTML Web storage is available only in latest browsers and hence browser compatibility would be a problem.
One other possible answer - you could use CrossPagePostback. This allows Page2 to automatically detect data passed from Page1. You'd have to do this on the page's load event.
A redirect will always take you to another page, and this will always lose any state attached to the first page. The only way you can maintain state like this is by not using a web application!
It's never really a good idea to keep the user information in a session and as little as possible in a cookie. Neither are secure and as you can see have some state baggage that seldom justifies it's use.
I recommend going back to the drawing board and designing a solution that keeps the information in a database obviously on the server; even if the record is purged at the end of the transaction. Watch that table and you'll be surprised how many sessions are dropped and never reach the "official" end of the transaction.
I'm using asp.net 4.0 with asp.net MVC 2.0 and the asp.net membership provider.
I need to terminate a the user session before I delete it. Otherwise if the user is still authenticated the next time it will visit a page null reference exceptions will occur when trying to access the user data and profile.
I get the Session.Abandon() method but what I'm looking for is the same on a user, something like user.AbandonSessions().
I realize this question has been asked before but I can't get a straight answer.
Thanks
I think you may be tilting at windmills. There are just too many things working against your desired goal.
If you adjust your perspective to embrace the arbitrary nature of a browser based app and instead of trying to eradicate all vestiges of a users state in order to avoid errors, rather take measures to ensure that the required data is present in the session and if not then recreate it or redirect the user to an appropriate location.
In any case, remember that in order to affect any session related action capably, you must force a request cycle to ensure the cookies are properly processed by the browser, but that is beside the point I am trying to make.
Good luck.
You could use a custom membership provider which instead of deleting an account, just deactivates that. You could also have the custom membership provider to lock the account at the same time.
FormsAuthentication.SignOut();
But you need to call it in the context of the user you want to sign out.
This question is related to this one, though I think I was a little too long-winded there to really get a good answer. I'll keep this brief.
I'm working on a web handler (ashx) that accepts a form post from an aspx page. When the handler receives this form post, in order to do what it needs to do, it needs to know the user who is logged in (User.Identity.Name), but I can't rely on cookies being sent by the browser.
I know I can get the Session.SessionID and place it in a hidden form field, but once my handler receives the form post, how can I use that SessionID to figure out the logged-in user's identity?
I'm using the StateServer mode for session state.
I think you can do it be implementing the IReadOnlySessionState interface on your HttpHandler
Unless there is a need to use session directly, you could always store whatever information about the logged-in user's identity in a singleton dictionary or cache and reference it via the SessionID stored in a hidden field. I personally see security issues in this but won't go into those. I would consider issuing single use identities for this type of implementation.
Jonas posted a great answer to this question here:
Can I put an ASP.Net session ID in a hidden form field?
In an HttpHandler or HttpModule implementation, you cannot always access session from the BeginRequest event. There is another event you can handle, called OnAcquireRequestState. If you write your code in that event, then HttpContext.Current.Session will not be null.