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.
Related
Does asp.net mvc5 really not come with some sort of default controllers and views to manage your users? things like creating a new role, and then assigning it to a user etc etc?
Is every single mvc5 website supposed to code their own?
Over and over again?
I get that we can now add custom fields etc to our users, but surely some sort of simple base built in manager isn't asking for too much?
Is there some magical nuget package or something I'm missing?
There doesn't seem to be anything like this.
I have added an item onto the asp.net uservoice list and you can vote for it there.
I'm marking this as closed.
http://aspnet.uservoice.com/forums/41201-asp-net-mvc/suggestions/5009231-add-a-default-asp-mvc-5-microsoft-aspnet-identity
Let's say that I have an MVC view that has one set of features available to non authorized users, and an extended set of features that is available to authorized users. Currently, I have implemented this by marking up my view with
#if(User.IsInRole(...)) {...}
in several places in the view file. This wasn't a big deal when it was just 2 or 3 things that authenticated users could do beyond the non-authenticated functionality, but now I have this all over the place in a "dashboard" type of page. It seems to be getting kind of messy.
Is there a cleaner or more elegant way to implement this? I am using viewmodels. I am wondering if I should use different viewmodels/views based on role, but then using different viewmodels seems like it might be more difficult to maintain. I am not sure what the best practice is for this, and I am open to ideas.
Edit
One example of what I am doing: I have several lists/tables that allows managers to edit the record, so the code adds an extra
<td>
for the manager-allowed actions. Another use case: when the manager is signed in, an employee name is now an actionlink instead of just text.
What you could try is encapsulating each portion of the view that will be interchanged based on roles into partial views. This has worked well for me in the past, and is much cleaner when trying to troubleshoot code as opposed to seeing a bunch of #if statements in a single view.
Hmmm. I have this idea. You need list of dashboards enumerations where you have a property like RolesAllowedToAccess (string[])
On the view you can foreach by dashboards enumerations where RolesAllowedToAccess contains current user role.
After you can render partials for each of dashboards. Make sence?
I would like to start using ASP.NET's membership classes and tables with a new MVC4 project I am building.
Let's say for example I want to keep track of user's birthdays. When creating the account, how do I add in the birthday? Is this something I keep track of with Profiles? I'm a bit confused on the correct way to add new 'columns' of data for users?
To specifically answer your question, here's how Microsoft advises to create extra tables for storing additional user information: Storing Additional User Information
Here is another posting (I would take this approach), its implementing your own profile provider, rather than using default one, so you have full control over what is happening, how it stored etc.: Implementing Profile Provider in ASP.NET MVC
Another great article by Microsoft about the same is Manage Web Users With Custom Profile Providers
It totally depends on utility and use. You can either
use default profile provider (exercising)
use custom profile provider (small scale sites)
use your own tables to store user information (enterprise level).
In the latter case you can link between default membership (assuming you using default membership provider) and your custom profile information by including user.Guid inside your table, which is used by default membership as unique identifier.
Hope this information will help you.
Profiles is the right way although it has its disadvatages. The data in the database is not in a readable way but in special strings, and profile is loaded on every postback.
Look here:
http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx
I have an existing ASP.NET application with lots of users and a large database. Now I want to have it in MVC 2. I do not want to migrate, I do it more or less from scratch. The database I want to keep and not touch too much.
I already have my database tables and I also want to keep my LINQ to SQL-Layer. I didn't use a MembershipProvider in my current implementation (in ASP.NET 1.0 that wasn't strongly supported).
So, either I write my own Membershipprovider to meet the needs of my database and app or I don't use the membershipprovider at all.
I'd like to understand the consequences if I don't use the membership provider. What is linked to that? I understand that in ASP.NET the Login-Controls are linked to the provider. The AccountModel which is automatically generated with MVC2 could easily be changed to support my existing logic.
What happens when a user is identified by a an AuthCookie? Does MVC use the MembershipProvider then?
Am I overlooking something?
I have the same questions regarding RoleProvider.
Input is greatly appreciated.
With MVC it is simple to bypass the Membership and Role provider framework altogether. Sometimes it is easier to do this than to implement custom Membership/Role providers, in particular if your authn/authz model doesn't quite fit the mold of those providers.
First, you should realize that you don't need to write everything from scratch, you can use the core Forms authentication API, which can be used independently of the Membership/Role provider framework:
FormsAuthentication.SetAuthCookie -
Call this after user has been
authenticated, specify the user name
Request.IsAuthenticated - Returns
true if SetAuthCookie was called
HttpContext.Current.User.Identity.Name - Returns the user name specified in the call to SetAuthCookie
So here is what you do in MVC to bypass the Membership/Role provider:
Authentication: In your
controller, authenticate the user
using your custom logic.If
successful, call
FormsAuthentication.SetAuthCookie
with the user name.
Authorization: Create a custom
authorize attribute (deriving from
AuthorizeAttribute) . In the
AuthorizeCore override, implement
your custom authorization logic,
taking the user in
HttpContext.Current.User.Identity.Name
and the roles defined in the Roles
property of the AuthorizeAttribute base class.
Note you can also define properties on your custom
authorization attribute and use that in your authorization logic.
For example you can define a property representing roles as enumerated values
specific to your app, instead of using the Roles property which is just a string.
Affix your controllers and actions with your
custom authorize attribute,
instead of the default Authorize
attribute.
Although you most likely can do this without a custom membership provider, I'm not sure that you save that much effort. Until I read this blog post I thought implementing one was hard, but it's really not. Basically you do this:
Create a class that inherits System.Web.Security.MembershipProvider.
MembershipProvider is an abstract class, so you are readily shown what methods need to be implemented.
The names are pretty self explanatory, so you can probably more or less copy your existing logic.
You might end up doing more than you need with this approach - but on the other hand, anything you might want to use now or in the future that requires a membership provider will already have its needs met.
The source of the SQLMembershipProvider is available here http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx. Take that as a base.
It looks a bit much at first, but you only have to implement the methods you need.
Yes the AuthCookie is used. Yes its a good idea to use the MembershipProvider, because it is well known by other developers.
There are thinks I dont like about it: For example It is not possible to have a transaction that spans the creation of a user by the membershipsystem and some other data in your own datbase. But still it works well.
I know what are you saying already (baad idea), but please read first :)
I am developing ASP.NET MVC based app, which will require some specific features:
combination of "local" users and facebook connect login, but FB users will be "mirrored" to some kind of local representation, because there will be some statistics and other stuff needed to keep for both types
authorization will be 3-layered instead of asp.net standard 2 layers. By this i mean : User is in Group (m:n) and Group is in Role (m:n), instead of User is in role (m:n).
So, if i would want to use standard authentication/authhorization approach, i would have to:
implement custom Membership provider, and it wont be even "right", because it will utilize methods like AddUserToGroup and AssignRoleForGroup etc.
implement custom Principal/Identity for sake of accessing my own User objects
casting HttpContext.User to my object every time needed...
implement custom Role provider
custom mechanism of sessting AuthCookie (unique userId in userdata, cant rely on username with third-party FB users in system)
... (you surely can think of something else)
Well, i really dont like the idea of "bending" and replacing every part to get pretty messy solution in the end. So I think of implementing my own mechanism encapsulated in one place - lets call it AuthService.
AuthService will be thread-safe singleton
Instead of AuthCookie will be using standard Session object (i know sessions also use cookies, but i really dont see advantage of low-level storage (cookie) over session)
AuthService will provide AuthService.CurrentUser (of my own type), populated from session on beginning of every request (Application_AuthenticateRequest, I think)
AuthService will provide in one place all methods - ValidateUser, RolesForUser, IsInRole, Logout, etc.
So now.. why should I not do this this way ? :)
I think session is equally secure to AuthCookie (same risks for ticket and authcookie)..
I dont really look for "modularity" (plug-and-play role providers, membership providers, profile providers..) - I deal here with pretty specific stuff, I dont expect standard components to fit.. have "my approach" any other disadvantages ?
Thanks for all good ideas and sorry my terrible english, I am from non-english-speaking country :)
R.
I can certainly see why you don't want to implement an entire Membership provider. However, I would take advantage of the low-level support offered by Forms Authentication (e.g. the cookie, expiration etc.) and just do my own custom authentication. If you do this, you can inject your own custom user class into the HTTP context and use it throughout your code. Your custom user object would implement IIdentity and IPrincipal. Your IPrincipal.IsInRole would work against your custom authentication scheme. This would allow your higher level code to use standard .NET framework permissions stuff. This is the neatest, simplest way to accomplish what you want while taking advantage of what already exists.