I am just learning the admin side of this in the Web Site Administration Tool, having set up a new project. I have accessed the security panel at the back end, and created an admin role, which is used to access a view through a controller filter. All standard stuff.
However when I try to log in to the front end with this user, it doesn't exist, and I have to create it afresh.
Alternatively when I create a user at the front end, and try to assign him an admin role at the back end it he also doesn't exist.
Only users created at the back end, exist at the back end and can be assigned roles
There seems to be no connection between front end users and back end users. There appears to be two separate databases one holding front end users and one back end users.
Giving a backend user admin rights doesn't seem to work from the front end.
is there some explanation on how this system work around? I have used google without help.
If you're using a standard asp.net mvc 4 application, then yes. This is to be expected.
The reason is that MVC4 by default users a different membership provider called SimpleMembership, and this provider is not compatible with the ASP.NET Configuration utility. That configuration utility uses the old membership provider, which has entirely different tables.
Your options are:
don't use the web configuration utility. Add users manually, or through a script, or maybe create your own admin pages.
Disable simple membership so that MVC uses the old membership system
do something completely different (don't use membership, use a different provider, create your own provider, etc...)
As for a separate database, yes. If you notice, there is no membership configuration in your web.config. Instead, the ASP.NET Congifuration utility uses the default membership configuration that's defined in your machine.config in c:\windows\microsoft.net\framework[64]\config. the default location is a file located in your project directory under the App_Data directory called aspnet.mdf
EDIT:
More information about the new provider here:
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
Also:
http://geekswithblogs.net/Aligned/archive/2012/08/30/mvc-4-authentication.aspx
Related
We are looking at enhanching our current security access model which is basically a check if the user is logged in. We now require the acesss to modules and pages and possible certain sections in the page such as dropdown restrictions based on your role.
I'm not sure how to design but maybe a few pointers and writing the requirements here will help.
The user usually belongs to an company.
The user usually has a role within that company
The company is made up of 1 or more sub companies
The user/role can have access to some modules in the system
The user/role can have access to some or all sub companies.
A role must be completely configurable on the fly.
A interface is required to configure the access for the users and the roles.
The menu needs to be configured based on access rights
The page needs to be configured based on access rights
We are using asp.net 2.0 at the moment but could possibly upgrade.
So based on that I think we need
User, Group, Role ( but roles need to be configurable) and Modules
A role for one organisation may have same name but have access to completely different Modules.
I am not sure asp.net membership is suitable so would like some opinions as it seams that access to pages is all hardcoded in config etc?
Yes, you can use ASP.Net Membership Provider for what you have stated.
As you said you are using ASP.Net 2.0, you cannot use new ASP.NET Universal Providers which is based on Entity Framework.
However, Membership Provider is introduced in ASP.Net 2.0. So you can still use the old version which uses aspnet_regsql.exe to create tables with the correct schema.
Here is the link for step-by-step instruction -
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
Please note that you cannot migrate from old ASP.Net 2.0 Membership to new Universal Providers.
I'm writing an MVC application, using ASP.Net Membership for security. The application will allow multiple websites to run from the same app and database.
The websites running on the app will be completely independent from each other. The users of those sites will have access to their site only.
If I'm using one web.config, one MVC app and one database, can I achieve site specific security using ASP.NET membership?
Presumably I'll only have one application key so won't be able to use that to differentiate between sites. I thought about using Roles but will be exposing roles to site administrators -- and don't want admins to add / configure roles for a different site to their own users.
This potential problem has only just occurred to me so any help will be greatly appreciated.
You could you have them as sub sites of the main site (with web.config setup there) and therefore, the authentication permeates through the sub-sites.
There is an ApplicationName property that the roles provider uses to filter roles on. Try setting that property before fetching roles.
Something like this should work:
Roles.ApplicationName = "MyAppName";
var authorized = Roles.IsUserInRole("Some.user", "admin");
I haven't tried this, it is a static property and could give you weird results, so be careful. The best way to do this would be to implement your own provider so you could do something like Roles.IsUserInRole("some.user","admin","MyAppName").
i'd like to create a Unique Web Site Administration Tool (UWSAT) to admin all users for all my websites on production server.
Basically the idea is to have the UWSAT with only an admin user; when the admin log the tool he could navigate the applications, select one and see its users . He could add new user to an existing application, or create a user specifying a new application name (as far as i know that create the application too).
The problem i'm facing is that to add a user to an application i have to set the Membership.ApplicationName but i read this should be avoided.
So i ask you : should i create a different MembershipProvider for each application and call it when i have to manage users for that application?
Thanks.
I recommend creating a role, and assigning it to the users. The role would be the application they should have access to.
The RoleProvider is one way to do this.
Currently using DNN 5.2.x and we are using only 1 portal on the site. We need to make a mobile version of the portal and eliminate most of the extra DNN stuff as info will be just displayed. So what we decided to do was create seperate ASP.NET Web Forms website and utilize the DNN providers (membership, roles, etc) to do the logging in. However we are currently having issues. The one in particular is ("unknown exception trying to write to log"). We've moved most of the DNN Global.asax (i.e. SimpleContainer instructions) file to the new website and added the necessary web.config sections and references however we get this error when a user logs in. We did copy over the same web.config machine key to the new website. The connection strings are also there (app settings and connection string sections and is named SiteSqlServer).
So my question is, has anyone created a new website around DNN without using DNN except for the membership? i.e. no modules, no skins, etc. Just validate user and get roles.
If you have what needs to be done to get DNN 5.2.x (or later) to log a user in and return the roles, could you post your steps?
The default DNN login is based on ASP.NET membership. If all you really want is the login feature, it will be MUCH MUCH easier to simply use the ASP.NET membership directly than try to rip it out of DNN.
What you are trying is not impossible, but certainly will require substantial patience with trial and error.
For only validation users and getting roles you could write your own simple providers that utilize dnn special tables in the databse like (Users, Roles, UserRoles, Profile etc). The table User is associated with the aspnet_Membership and aspnet_Users standard tables via the Username field.
There are many options which are open for you.
If you really don't want to digg into complecations of how to integrate the dnn membership and role provider will work, you can check dnn single sign on
Another option is to have your webforms application as a subfolder in your dnn website. that way you don't have to do much effort and you will have all the good things ready to get started. even you can directly convert your skin to master page and reuse almost all the css and image related suff
In addition to above, I also suggest another smart way to do this. Since you are considering a mobile site, why don't you try and detect the browser using Request.Browser and create a separate skin for dnn that is of smaller size. We can easily switch skins dynamically for service requests.
I hope this will help. If you have more questions regarding this, I will be happy to help. Just drop me and email and I will try to help you get as close as possible to get you going.
Good Luck
This is the route we took. We basically implemented DNN in the mobile version of the website. Except we only utilized the User Membership features of DNN. To do this we had to use all the same core DNN dll's and also include all the "bootup" features in the global.asax file. We also had to on every request inject a UserInfo object into the session context. I forget the key name for the UserInfo oject used but it is used by DNN and must be set in a DNN handler that we did not incorporate. Other than that it works perfectly. We have the ability to get all the roles a user is in and etc.
I want to know whats the "right" way to setup membership in a new website.
When i have new project i can go to Website/ASP.NET Configuration. There i can setup Forms authentication and manage all users that will be using this page. I can make roles and rules on folders. All of this info are saved into table that will be saved locally in database App_Data/ASPNETDB.MDF. What i'm trying to do is that all this info would be on a host server along with the website but not locally.
What is the best way to connect my website that i made locally to a mssql server that is central. I want to be able to go to the asp.net configuration and manage users but i want the data to be saved in the tables on the mssql server not to the aspnetdb.mdf file.
I have already made the asp.net membership tables on the mssql server by using the aspnet_regsql.exe file.
Update:
Never mind, i found out a way to to this.
Just had to add
<remove name="LocalSqlServer"/>
in <ConnectionStrings> and then my own connection string. Now its working...
There is a line command in the Visual Studio SDK called "aspnet_regsql". It opens a window, and you can use it to set up the ASP.NET membership, roles, and profile support in any SQL Server database.
For most applications, you'll probably end up writing your own membership admin pages. It's not hard, and most of the controls you need are in the toolbox in Visual Studio. Here's the cookbook I've given in presentations on security:
To add ASP.NET membership and roles to an existing SQL Server database:
Open a Visual Studio 2008 command window.
(If you must run SQL line commands in Administrator mode, you will need
to open a command line in administrator mode, then set the path to
include the Visual Studio SDK executables.)
Run aspnet_regsql in that command window.
For the SQL user logins that will use the database, add one or more
of the following membership provider roles:
aspnet_Membership_FullAccess - if users can register themselves or others
aspnet_Membership_BasicAccess - users cannot register themselves
aspnet_Membership_ReportingAccess - for membership statistics
For the SQL user logins, add one or more of the following role provider roles:
aspnet_Roles_FullAccess - create and delete roles
aspnet_Roles_BasicAccess - use asp.net roles
Configure your initial application and roles using SQL Server Management Studio:
exec aspnet_Applications_CreateApplication #ApplicationName='Northwind',#ApplicationID=''
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Employee'
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Manager'
exec aspnet_Roles_CreateRole #ApplicationName='Northwind', #RoleName='Master'
Implement your "New User" page, but don't lock it down with forms authorization yet.
You may want to implement your own form, assuming you have user records already existing
in your database, and assuming that you'd like to add roles as part of the "create user"
process. In any case, use this page to create an initial set of users for ASP.NET
membership; it's easier this way than trying to make it work with stored procedures.
See sample code for an implementation of user creation without using the ASP.NET
LoginView control.
Note that this "Add a User" page in the sample application assumes a number of things
that are hard to do with the standard Login control in ASP.NET. If you're creating users
as an administrative function, rather than letting users add themselves, you probably
want to have multiple roles, and be able to select the role. Even more important,
you may have "user" tables already established in your database, and need to integrate
"new user" functionality with adding records to your application's user table. This is
a prototype for creating your own Login control, collecting additional data and
integrating the creation of user records, ASP.NET membership records, and ASP.NET role
assignments. All of this is done within an ambient transaction, so they either succeed
or fail as a single unit of work.
Once you've created users and added them to roles, you can set up forms authentication
and lock down your pages that require authorization. Notes:
a. Don't require authentication for your top-level directory. Pages at this level
should be publicly accessible.
b. Add a web.config in each subdirectory where pages require authentication.
Usually, setting the authentication level will be the only function in these
web.config files.