I have a website that is already built using the default aspnet membership provider. I am looking to expand it in order to slightly modify the functions.
From my understanding, I would want to create a custom membership provider inheriting from the membership class, and then overload the functions. I got that far, but I was unable to figure out how to call the original validate user.
My goal was to change the validate user to something like...
public override bool ValidateUser(string userName, string password)
{
if(base.ValidateUser(userName, password))
{
\\Write to database that User logged in
return true;
}
return false;
}
However, when I tried that, base.ValidateUser(x,y) threw errors. How would I go about achieving what I want to?
My guess is that you have inherited from the abstract MembershipProvider class. If this is so then calling the base class method is of course impossible as there is no implementation in the abstract class.
If, on the other hand, you want to call a base class method, you have to inherit from proper base class, like the SqlMembershipProvider.
Related
I have to edit the Login/Registration that ASP provides to include a custom dropdown ("BranchID") menu that saves to the database so each user has its own Branch. I am using ASP Membership system, and of course it saves to the ASPNETMDF database it creates. Googling has net me some results but I am quite confused. I know there are "User Profiles", and I I can save this Profile data, but what I am not quite sure is if its a temporary measure or if it does record to the database.
I could make my own custom membership system, use the built it and adapt it or use the user profiles. What is the best course of action? I'd vastly prefer to adapt/edit the built in Membership system and add the data I require to it but I still don't haven't a clear answer to what I should do or what's best.
You have two choices:
Create a CustomMembershipProvider , and if you need to a CustomRoleProvider, you can do this by implementing .NET's MembershipProvider. Sample: http://www.codeproject.com/Articles/165159/Custom-Membership-Providers
Create a separate table that stores additional user information, i.e., "BranchID", and add a one-to-one relationship between your table and .NET's Membership
It's really up to you which one you choose.
MembershipProvider is pretty easy to extend. Assuming the branch is something they have to select to authenticate? You should be able to extend authenticate to do something like:
public class MyCustomMembershipProvider : MembershipProvider
{
/*
....
*/
public bool ValidateUser(string username, string password, string branch)
{
return (::ValidateUser(username, password) && MyCustomRoutine(username, branch));
}
}
In my ASP.NET Web API controller, I want to restrict access to those in the User role. The common way to do this is to extend the AuthorizeAttribute (example, example) and then sprinkle my controllers with my custom attribute (e.g. [AuthorizeUser]).
Another way to do this is to add a function in the controller's constructor. The constructor is required anyway because I'm using dependency injection.
Here's some code:
public class MyController: ApiController
{
private IUnitOfWork unitOfWork;
private IAccountUtils accountUtils;
// Constructor
public MyController(
IUnitOfWork unitOfWork,
IAccountUtils accountUtils)
{
this.unitOfWork = unitOfWork;
this.accountUtils = accountUtils;
// Restrict access to 'User' role
accountUtils.ThrowExceptionIfUserNotInRole(User.Identity, "User");
}
// More code
}
Because there are countless tutorial and examples of using a filter to authorize users I assumed that was the best way to go. However, when I stepped through my code in the debugger I found that the constructor method gets fired BEFORE the filter.
To optimize code, it makes sense to break as soon as possible if the user is not authorized to access the controller. If I'm not mistaken, then, it should be more efficient to perform authorization in the constructors instead of in a filter. Am I correct or am I missing something here?
It seems like your main concern is optimizing your code, and you're correct to note that the controller constructor runs before the authorization filter. But the difference in performance between those two solutions is extremely small and shouldn't really impact your service.
While throwing from a constructor might work, it's not the most elegant solution because it requires you to authorize in code rather than declaratively with an attribute. It also forces you to mix object instantiation logic with authorization logic which isn't as clean.
So I'd recommend just sticking to using an authorization filter for this one.
I'm working an a ASP.NET application (not using MVC) and need a User-Role-Permission based authorization scheeme, where pages and/or methods can demand the specific permission they require (instead of which role the user has). Is there a way to extend Forms Authentication (or building something) to solve this?
If possible I would like to be able to use attributes:
[RequirePermission("UserEdit")]
public partial class EditUser : System.Web.UI.Page
{
}
Perhaps even for methods:
public class MyClass
{
...
[RequirePermission("UserEdit")]
public void Save()
{
...
}
}
Is this possible?
I found this page, that suggested using Roles for permissions:
[Authorize(Roles = "UserEdit")]
public partial class EditUser : System.Web.UI.Page
{
}
I am not very fond of this solution, but that would also be a possible way to solve things, but what do I need to do to get it working?
Microsoft's authorization model sucks...and it's widely acknowledged
http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/).
That said. It's nice to have cross compatibility by fitting into their IPrincipal.IsInRole API (and thus being able to leverage the Authorize attribute)
So...what I do to compromise is have a full permission model in the DB with Users, Roles, and Permissions...but when my code sets the CurrentPrincipal I flatten the User's Roles and Permissions into the Roles collection of the IPrincipal. It's far from ideal...but IMHO it's a decent compromise. Others (Rockford Lhotka) have also taken this approach: http://www.lhotka.net/weblog/PermissionbasedAuthorizationVsRolebasedAuthorization.aspx
In my asp.net application admin functionality, I am trying to combine AD authentication and form authorization for creating the users, roles and Assign users to roles etc. I have configured MembershipADProvider and AspNetSqlMembershipProvider in my web.config with MembershipADProvider as the default one. After user logs in using AD authentication, I need to switch/assign my membership object to use AspNetSqlMembershipProvider in order to get all the users from membership object (from dbo.aspnet_Users table). How do I switch the provider during run time? I have tried different approaches after searching for this issue and none of that seem to work for me so far.
Here are couple of approaches I tried:
1. foreach (MembershipProvider mp in Membership.Providers)
{
if (mp.Name == "MembershipADProvider")
{
Membership.Providers.Remove(MembershipADProvider");
MembershipUserCollection users = Membership.GetAllUsers();
ddlUsers.DataSource = users;
ddlUsers.DataBind();
break;
}
}
Membership.Providers.Remove(MembershipADProvider"); - doesn't work as it's not supported..
Also, tried to clear the Membership.Providers and then add only the type of AspNetSqlMembershipProvider which are also not supported.
I can't set Membership.Provider with value from
Membership.Providers["AspNetSqlMembershipProvider"] as Membership.Provider is a read only property.
I tried to swtich the connection string between 2 providers, which didn't swtich the provider, as both are different types of providers..if both were sqlserver providers this would have worked I believe.
Please let me know if anybody has successfully implemented or if at all this is a plausible approach. Thank You!
You would pass an explicit provider to your code, rather than taking a dependency on Memebership directly (which just wraps the one flagged as default in the config). There is no need to swap them in and out at runtime, think how this would affect thread safety.
So rather than saying Membership.GetAllUsers(); you would do something like (I don't have a compiler to hand):
public UserSerivce : IUserService
{
private MembershipProvider provider;
public UserService(MembershipProvider provider)
{
this.provider = provider;
}
public IEnumerable<MembershipUser> GetUsers()
{
return provider.GetAllUsers();
}
public void DoSomethingElseUseful()
{
...
}
}
And then to use it for a particular provider:
var service = new UserService(Membership.Providers["mySqlMembershipProvider"]);
var users = service.GetUsers();
Or if using AD specific code:
var service = new UserService(Membership.Providers["myADMembershipProvider"]);
var users = service.GetUsers();
Using DI in this way also helps keep code testable.
If all you need a list of users in the aspnet_Users table, just connect to your database with System.Data.SqlClient objects and query the table. There is no reason (that you mentioned) you need to use a membership provider to get that data.
Having said that, your membership/authentication scheme sounds like it may have some design issues, perhaps best tackled in a different question, but I think it might be useful to you if you sought comment on what you are trying to accomplish overall with the multiple membership providers.
Edit: I found some potentially useful posts on using multiple membership providers. It looks like the general idea is to implement custom code handling the Login.Authenticate event on your Login control, and use Membership.Providers["ProviderName"].ValidateUser to attempt authentication with each provider.
http://www.stevideter.com/2008/03/20/using-two-membership-providers-for-aspnet-logins/
http://forums.asp.net/p/1112089/1714276.aspx
I am trying to implement a custom membership provider and want to change the GetUser method. The problem is that GetUser returns MembershipUser and I want to return MyMembershipUser which has two additional properties FirstName and LastName. I can create a new method in my membership provider which returns MyMembershipUser but then I think it won't make any sense.
How would I go about doing this?
That would defeat the purpose of the Membership classes. Do something like this if you need to access other properties:
var user = Membership.GetUser(userName, true) as MyMembershipUser;
Really you should have a separate Profile class that handles things that MembershipUser does not provide.
var profile = Profile.GetProfile(Membership.GetUser(userName, true));
You should go for Profile Provider.
check this link, you have either SqlStoredProcedureProfileProvider and SqlTableProfileProvider, this way you have ability to store Profile data “in the clear” in the database, letting you query the db whenever u want.
"you can implement whatever business logic you need in the stored procedures to map the Profile data to your own database schema and database logic."
If MembershipUser is the base class of MyMembershipUser then you can return instances of MyMembershipUser even though the return type of GetUser() is MembershipUser and then, if necessary, cast them back to MyMembershipUser (but do you really need to do that?)
BTW, this is an example of polymorphism.