views:

74

answers:

6

Hi!

Gotta tell you... I've searched the internet for weeks now, and still haven't found a reasonable answer.

My problem is quite simple - I think. I'm doing an ASP.NET MVC project. It's a project that requires the user to be logged in at all time. I probably need the current users information in the MasterPage, like so; "Howdy, Mark - you're logged in!".

But what if I need the same information in the view? Or some validation in my servicelayer?

So how to make sure this information is available when I need it, and where I need it?

Thanks!

+1  A: 

I've had exactly the same issue, and have yet to find a satisfactory answer. All the options we've explored have had various issues. In the specific example you mention, you could obviously store that data in the session, as that would work for that example. There may be other scenarios, that we've had, where that may not work, but simple user info like that would be fine in the session.

We've just setup a BaseController that handles making sure that info is always set and correct for each view. Depending on how you're handling authentication, etc, you will have some user data available in HttpContext.User.Identity.Name at all times. Which can also be referenced.

Chops
A: 

Build a hierarchy of your models and put the shared information in the base model. This way it will be available to any view or partial view.

Of course it has to be retrieved on each request since web applications are not persistent.

User
A: 

You should store this in Session and retrieve it into your controllers via a custom ModelBinder.

Kieran Benton
The only issue where we've had problems using the session is for data that may vary depending on the area of the site you're in. For example, we have a series of Leagues in one of our apps where sometimes the user may be a manager, sometimes not. We have to store whether a user is a manage in the session. This works great until you have multiple tabs open, and then it all starts getting very messy. So it works for login info, but falls down when you start using it for other data potentially.
Chops
Can you explain that part of your problem in more detail? It sounds as if you want to look at federating your login model using roles to a greater extent.
Kieran Benton
It's not quite that simple, we have a single user who may have multiple roles within different elements of the site. marc_s's suggestion below might actually address that issue for us. We're having a play with it some more to see if it provides a good solution.
Chops
+2  A: 

How much user information do you need? You can always access the Thread.Current.Principal and get the user's name - and possibly use that to look up more info on the user in a database.

Or if you really really really need some piece of information at all times, you could implement your own custom principal deriving from IPrincipal (this is really not a big deal!), and add those bits of information there, and when the user logs in, create an instance of the MyCustomPrincipal and attach that to the current thread. Then it'll be available anywhere, everywhere, anytime.

Marc

marc_s
A: 

Not sure if I get what you want to ask, but if you are looking for things like authentication and role-based authorization, actually ASP.net is providing a great framework to work on/start with.

This article (with also 2nd part) is something I recently discovered and read about which is really good start with the provider-pattern which help to understand the underlying authentication framework of ASP.net. Be sure to read about the membershipProvider class and the RoleProvider class in msdn also, they together make a great framework on most basic role-base authentication to work with (if you are comfortable with the function they provided, you even don't need to code data-access part, all are provided in the default implementation!)

PS: Check out Context.Users property too! It stores the current authenticated user information.

xandy
A: 

HttpContext.Current.Users.Identity returns the current user's information. Though I am not sure whether it gets passed implicitly when you make a webservice call.

Ramesh