I'm using ASP.NET MVC and when I have an user logged in using forms authenticaion, I would like to keep some information about this user. The HttpContext User object, implemented from IPrincipal has some properties, but I would like to add some more, so that I could get these on my actions and views. What's the best way to achieve this?
Thanks
We have used this in the past to store additional information about the user in the Forms Authentication cookie: http://formsauthext.codeplex.com/
Seems to work fairly well and prevents a few database hits since some basic information is available from the cookie. Also, going this route prevents issues around sessions (expiring, app recycling, etc).
You could use the Membership, Role or Profile providers to persist information about your users.
Thank you, but I found out this blog post that helped me with this issue: http://www.creatingsoftware.net/2007/11/aspnet-20-forms-authentication-keeping.html
Related
i've a question regarding handling of user logon while porting an application to MVC:
in the "old" WebForm days, developers simply used the SessionState object to set a user to logged-on, by -for example- simply putting the userobject into the SessionState (and this userobject holds simple properties like name/lastlogon/etc.)
this stuff worked very well for us, and i've seen lots of applications doing it that way
yes, i know there is this MembershipProvide-thingy, but i've never used it
Now, in MVC, everybody tells me that "using SessionStat for this is bad" and "apps built that way are flawed in design" and that "there are tons of security risks" and so on.
I've used this method because it worked for the app very reliable, it was simple to implement and it covered all stuff we need.
(Sure, there is the thing with recycling web worker process and emptying the session - but thats not a problem in our case, since the app runs for each country on a dedicated machine)
I've read tutorials, telling me to put that stuff in the DB and -attention- doing a request to the DB to check if the user is logged in, per EACH request? But: Under no circumstances, this is a doable way since i want to keep DB requests on a minimum.
So my question is:
A) whats wrong using this way also in the new MVC app?
B) whats the best way to handle this scenario in a newly built MVC app?
Regarding the session-in-DB-idea: instead of doing this, i'd rater setup an additional service, like a "session-manager" thats get query over the network, but such simple requests should not go to the DB - isn't that a good idea?
Any idea, hint /etc. is highly appreciated since this scenario is really confusing me :-X
A)
A fundamental principal of the asp.net mvc framework is that its stateless. Data is passed around using http requests and sent to the views in viewmodels. Web forms tried to maintain state with viewstate etc thats why you would have seen the logged in user in session approach. Thats not to say session shouldnt be used completely in asp.net mvc, there are some circumstances when it can be useful. Like maintaining a 3 step form process that has to be persisted on the last step. But generally we already have a recommended way to handle the user logins, and thats forms authentication
B)
For accessing the user object, you can create a custom identity implementing the IPrincipal interface and add the required user fields you need. Then set the custom identity in a global filter and access it in your action results. Regarding not wanting to query the database for every request, why dont you just call it for the initial request, then cache the result until the user is updated where you then can reload the object and set it in the custom identity again.
First of all it's important to note that in my application if you log out your session is still valid and you don't just get redirected back to a login page, but stay on the same page.
With that said - whichever of these two ways I use to sign out in an MVC application
FormsAuthentication.SignOut()
WebSecurity.Logout()
the effect is the same and neither of the following properties changes to reflect the logout if I immediately access them :
User.Identity.Name
Thread.CurrentPrincipal.Identity
Now - If I do a Redirect, or just reload the page then obviously these properties are updated to a null user. They just don't immediately meaning that User.Identity.Name represents a user that just logged out.
This is a problem because I want to generate text of the form You are logged in as XXX after login/logout - and this may be in an AJAX situation where a redirect isn't possible.
I'm curious if there's any way to trigger the IPrincipal to reset itself after a logout (or login).
I assume people normally just Redirect() after a Logout() call so this is never an issue, but in an AJAX situation this is not always practical.
My current solution is to abstract the Identity in my own wrapper, and so once I'm logged out I can just update that. I'm just a little concerned that this could have some obscure side effects especially if somebody accesses IPrincipal directly adn not through the wrapper.
This is a core limitation of the ASP.NET event pipeline as it relates to forms authentication. This also makes it vulnerable to replay attacks, as described in KB article 900111. In that article, they reference one solution to use a membership provider that stores some server-side information about the logged on user.
Membership provider seems very similar to the approach you are thinking of taking, and I wonder if you should consider using one of the built-in membership providers, or writing your custom code as a membership provider. This should address some of the concern about people not understanding the approach and calling the IPrincipal directly.
Your "logout but stay on the same page" brings the issue a little more to the fore, but ultimately you're just uncovering the same fundamental replay issue that everyone has with ASP.NET (but not everyone solves it).
This related question may also be helpful.
I need to implement some (maybe 10) custom properties for logged in users for my MVC3 vb.net web app.
These will define how certain data is displayed within my views.
I can think of a couple of possible solutions..
Session variables. Will do the job but seems a bit untidy, and
can't be strongly typed
custom properties of the current user object; is that even possible?
Custom profile provider. Looks like it might be a good option.
Has anyone got any tips on what worked well for them?
I already have custom membership and role providers that are working fine.
Thanks!
First solution - use standard ASP.NET Profile Properties feature.
If for some reasons you can't use that - then I'd vote for custom profile provider.
I have created my own MembershipProvider for my ASP.NET MVC 3 application and have it working great.
Once logged in, I can call the logged in user's username by requesting System.Web.HttpContext.Current.User.Identity.Name.
I'd like to store some additional information about the user here which needs to be reused throughout the application.
Could anybody help me out with identifying the best way to do this, possibly with some examples?
You could use a custom Profile Provider to achieve this. And here's a blog post which you might find useful as well.
have a look on this..may be helpful for you
http://www.asp.net/web-forms/tutorials/security/membership/storing-additional-user-information-cs
I am creating an Asp.net MVC application and I'm currently using the built in Authentication/Authorization code that comes with the sample MVC app. For the most part this is working ok and I kinda understand what's going on.
What's concerning me though, is that now I kind of have my users stored in two different tables across two databases. i.e. I have users in my App's database that represent the "Customer" entity in the application, as well as the "User" in the Authentication database that's used to log in someone to the app.
Should I take the logged in user's User.Identity.Name value and do look up in my Customers table or should I merge them into one table? What's the best practice way of handling this?
Please forgive my ignorance - this is the first time I'm working with a system like this.
Any feedback is greatly appreciated!
It's helpful to think of credentials and the records that associate a person to application data as two very different things. Depending on the application, your Customer may not have credentials to log in or you may have an administrative User that logs in but isn't related to your application data.
Separate credentials are also useful if Users access more than one application with different rights for each.
For these reasons, I'd keep Customer and User separate and look one up from the other where appropriate.
You can extend the .Net Membership Provider to take all the information you want and post back in a single model I think.
See this one ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?
And this one How to implement ASP.NET membership provider in my domain model