In my app I want to add properties to the user class.
How should I do it?
My current solution is to create Users table in th database, but I just read that Asp.Net provides out-of-the-box users registration API and functionality.
How can I update the new properties?
Thank you
Do you mean you want a custom Principal? In that case you want to hook into the AuthenticateRequest method and add your own, derived principal. I recently answered a question regarding the creation of a custom principal here. While that question deals with WindowsAuthentication, the idea is the same:
Get the current authenticated principal,
use it to create your own custom principal,
set your principal on the HttpContext and Thread.
You can write a custom Membership Provider that plugs into the membership & authorization features built into the framework. You can also write your own custom User class that inherits from the standard class. You can design it so that it uses your existing users table if you want.
This has worked out well for us on a couple different projects.
Here's some documentation:
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
Related
I am relatively new to the UI5 Framework and I have a new use-case in my company that I want to implement with UI5 and OData Services.
Basically the application has two functionalities with different stakeholder:
Role A is able to create new requirements
Role B is able to check the requirements and update them with new
information
How can I implement this the best way? My previous thoughts on that:
Possibility 1:
I have the OData Service in the Backend that is used by two separated application depending on the role. The access is controlled through the launchpad over the PCFG objects. So a specific user can only use the application that he actually needs. I believe that matches the basic granularity of Fiori apps. On the other hand, it invalidates the DRY principle since I would have redundant code like most of the view.
Possibility 2:
I check in the UI5 Framework or OData Service which user is currently using the app and enable/disable the required controls in the controller class. I haven’t come across on how to do this. Is there a way to check which user is logged on? Or how can I implement in the OData service, that only specific information is delivered to the client?
What is the correct way to implement such a use case? Is there a better option that I am not aware of? I would appreciate any thoughts on that matter, thanks :)
Best regards
Suggested Approach
If two roles do not share any common functionalities, then I would go for two separate UI5 apps, so as to keep them simple. In that case, each app would have it's own OData service. But in the backend, you can always have a common class for 'Requirements' which is called by both the OData service implementations. (So as to maximize code reuse). So most of your business logic should be inside the 'Requirement' class, and the OData implementations serve as dispatchers.
To check which user is logged in
This is a common requirement for most of the business applications and it is possible in Gateway/ABAP as well. Within the ABAP context, there is always a system variable available named SY-UNAME, which will provide you the current logged in user's name. You can use it further to derive the user's role.
hello everyone
i have a project where am using ASP.NET Identity 2.0. in this project am following the Onion architecture.
the layers are :
1.UI: no reference to Owin or ASP.Net Identity
2.AuthenticationService:contains a wrapper for the asp.net identity usermanager.this wrapper implement an interface that lives in the Bal layer.this layer also contain my custom UserStore.
3.Dal: DbContext lives here.
4.Bal: contain Domaine entities and interfaces .no reference to Owin or ASP.NET identity or anything else.
5.DependencyResolver: Owin Startup is here plus some Ninject Modules and the NinjectWebCommon.So am Using Ninject.
till now everything is fine. users are happy creating accounts and ,they can login/logout/manage any time they want.the problem am facing now is with the Authorize(Role="rolename").it just doesn't work.
[Authorize(Users="pedro")]
[Authorize]
both of these works
[Authorize(Roles="Admin")]
this is one no.
in my Database i have users who belongs to the Role Admin.I am not sure why this doesn't work.mybe because i moved all the authentication stuff to another layer so the IPrincipal.IsInRole(string role) can't figure out how to check this anymore.
am working on creating a custom Authorize attribute or create some extensions. but i decided to seek your advices first.
Thank you for your time
well Here i am answering My Own Question.
Indeed the problem was because the Method User.IsInRole(or IPrincipal.IsInRole because User is an IPrincipal). Inspecting the code of AuthorizeAttribute Using Reflector Shows that this Attribute uses the IsInRole Method To Check if The Authenticated User Is In Role X or Xs.but here comes another question .why it can't do that , i mean why it can't find out if a user belongs to a specific role or not.
the problem come from the Cookie generated for the user.because roles are associated to the Cookie they need to be there so IsInRole can Find Them and this is where i made My mistake.I moved the Authentication and authorization to somewhere else but i didn't provide a way to embed the roles informations inside the cookie so the IsInRole (from User or from Roles) couldn't find them in order for the Authorize Attribute to do it's job as i wanted it to.so the good news is that i only needed to insert the roles inside the cookie somehow.
the better news is : ASP.NET Identity wich am using now support claims,and in 4.5 GenericPrincipal derives from ClaimsPrincipal wich in turn derive from IPrincipal,so i can work with claims rather than old fashion roles (wich we can still use if we want to).
well.if someone came across the same issue,i recommand the following:
1.Authorize Attribute needs that the cookie to contain all the informations you are trying to rely on (Roles,User Names).
2.use thinktecture Nuget rather than Authorize or ClaimsPrincipalPermission attributes wich gives you the pros of both of them.
3.Learn About Claims.yo will never regret it.
I am trying to convert my vb.net 2010 web forms application into a C# MVC 4 application. Since my membership is already setup, I would prefer to just continue using the membership provider instead of the simplemembershipprovider.
Hi,
I am using PluralSight to learn MVC, but have not been able to find any reference on how to convert membership code to mvc.
I have a custom table that is linked by UserID to the mememberships User table. This custom table, asp_customUser, stores additional information about the user.
In the account controller, there is a register action, with the view and model. The register process does not handle roles, much less my custom data.
What I would like to know is, how do I add roles and custom user information to the database, when part of the fields in the registration view come from the membership library and the other part go to my custom table.
Thanks
Yes, you can use the old membership. Just copy and paste your membership provider from the old web.config to the new one.
If this is running on a different computer, you may need to set the machine key, however, in order for it to be able to correctly validate the password hashes.
You would then remove the Simple membership initialization attribute from the Account controller, and you would need to remove all the other simple membership code. You would also be giving up the OpenId authentication, because normal membership does not work with WebSecurity, so you would have to remove all that as well.
When we wanted to extend the membership class we inherited the base membership class and used all the fields in it and the tables linked to it and then create an additional database table with a FK linked to the id in the membership table. Any additional parameters where in the new table and extended class and any standard parameters were in the std membership table and standard class.
What is the best approach to allow a user to change his email address?
im using the built in membership provider and AccountController. in asp.net mvc 3
My app is using Entity Framework but im not sure if its correct to add that membershipUser to the edmx and create a UsersController to do this... or add an action to accountController that handles this.
Please help
The membership provider has the ability to help you manage that. You would most likely add the ability into your AccountController to do this. I wouldn't add it into your EF classes. It is handled outside of your database anyway (unless you've written a custom MembershipProvider to talk to tables inside your database).
Take a look at this question too as it addresses some of what you may want to do and it includes source code.
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.