I am using asp.net 2.0. I have been using asp.net membership provider for user management. But I think this would be more efficient if I could do this without using role and membership provider provided in asp.net. In fact I see bulky markups generated when I add login control,
createuser control etc. in an asp.net web page.
By saying user management, I am referring to the overall login, user activity tracking, password reset/retrieval, role management in an asp.net web application. And I want to implement efficient way to accomplish this.
Any suggestion would be appreciated.
What exactly bothers you? Server-side code, or the HTML which gets served to the client?
If former, then you can implement your own providers or just reinvent the whole system from scratch (which I do not recommend, but it might be worth it in some scenarios).
If latter, just write your own set of controls that use Membership API.
As far as "efficiency" is concerned, you're not clear in what "efficient" means to you.
Most (all?) of the membership controls support templates, which means you can customize the markup they generate to the client.
See this tutorial to get you started: A Crash Course on ASP.NET Control Development: Template Properties
As for the database hits, I don't think it's a huge problem, but if you're concerned I'd suggest load testing it to make sure. Also, if you set CacheRolesInCookie to true, you can eliminate some of those database calls.
Related
I have two projects. One is an ASP.NET Mvc, and the other is a Web API.
The main project is the Mvc one. But I need to redirect the request to the Web API. All posts about it make clear that in order to redirect to another project, it should be a Redirect to an URL:
return Redirect("http://localhost:54270/"); //This calls the Get action in the Web API
But the problem is that I'm using an Authentication in Mvc that I would like to be validated in the called Web Api Action. Is it possible?
The session is not the same, so I cannot retrieve this information. Is there any way to share the same Context between both running sites? Or is it the wrong approach?
Yes, it can be done. In webforms, you can set the keys to hash values to the same key in multiple applications. As long as they are in the same domain, that is all you have to do. I have not tried it in MVC, but the internals are very similar. This is a bit of a kludge, but it works nicely.
In this simple way of doing it, you cannot share information, just the high level session information. As I have not played with this in MVC, you may have to set MAC settings or similar to get it to work. I don't have time to look this up. When I found this worked, the developers were still thinking in the ASP world, so they had a boatload of crap in the Session object which we had to sync up. You should not have this issue.
This method will not share the contents of session, but that should not be an issue if you are using MVC correctly.
If you want to go beyond this, there are ways to set up a single sign on mechanism. Anything that works for ASP.NET webforms should work in MVC, although you may have to add some code for items that would not normally be set in MVC that are required for webforms.
If you want a deeper understanding of the way it works, I would look up how people shared state in ASP and ASP.NET, as these pages generally have more information.
I have a usermanagement table into my sql server 2008 i want to check each user with their particular role frm my database & not from asp.net predefined database. please help me with the code for the same. also what i need to change into my web config file.
You probably want to implement (roll your own) version of the membership provider to make this job easier, more secure and less error prone - it will also save you writing tons of additional plumbing code.
In essence it means implementing the IIdentity and IPrincipal interfaces (Sounds scary but its really not that bad). See this blog here http://www.bradygaster.com/custom-authentication-with-mvc-3.0 for a step by step guide. Additionally it is worth reading the comments and links to enable proper Forms Authentication via Auth Cookie rather than the basic session management referenced directly in the post!.
Also note this example on the blog is for MVC 3 BUT its equally applicable to Web Forms projects too.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
Hai,
i am trying to store the user permissions for my web site.But I am little bit confused with xml and Database. For each user in site have different permissions. Have u ever faced this issue? for Example , if my site is a shopping site , for a local user , the report menu need not to display. A sales man need not to display the purchase page. and so on ..
I think you understood my problem .I have done this user management using a xml file . For each user a new node will create according to the menu and keep in the xml file . Next time the user login ,checks the permissions and and show only the allowed menus.
My boss tell me to do the same thing using the Database. by using XmlDataSource it is quite simple to bind data to the treeview (for setting permission) and binding to the menustrip also.
He is pointing the security problem . i don't think like so.
Which is better ? DB or XML
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
My advice would be to use asp.net membership and roles (written by Microsoft). It is a very good security solution - login security, roles (permissions) and is stored in a SQLServer database (not sure if it can be stored elsewhere).
I use it on my site and you can use membership controls straight out of the box (login forms, change password, etc.) or you can roll your own.
The only tricky bit I found was setting up the membership tables, views and stored procs in my dB (you download a dB script), but really it was fairly straightforward to implement.
Here's a link to asp.net membership and roles
ASP .NET Membership and Roles (part of the Provider Model introduced on ASP .NET 2) is (IMHO) nice only when you need some basic stuff. The issue is that you need to use the whole system using SQL Server, but if you are planning to move to a different DB provider (MySQL, SQLite, etc..) then you'd have to implement your own provider (which is at best painful), and learn how the whole pieces fit each other. Granted, finding a custom implementation it's quite easy, but is not a copy & paste thing.
Another bad thing of the default provider model is that you will get a ton of SQL stored procedures, also called maintainance nightmares. The issue is that if your site scales, then these SP's will make your life a living hell (been there) and if you even dare to change hostings then you're in for a treat, so my advice would be make your own permissions hierarchy and use it the way you wish. Also, look for advices and some pre-existing solutions to the permissions problem which is quite common.
Website security can be split up into to distinct parts.
Authentication: Logging in
Authroization: Roles/Permissions.
The ASP.NET Forms Authentication Provider is a great way to implement authentication. I recently created a custom provider that communicates with our companies X500 directory (LDAP). It was very straight forward.
For Authorization, we implemented the entlib security application block. It allows you to keep Roles/Permissions in a separate location that can be accessed by your UI as well as your service layers (assuming your developing a scale-able solution). You may also want to look at the Windows Itentity Foundation which is slated to supersede entlib security application block, however it is only available for .NET 4.0.
I am not sure how to phrase a good question, so I will just say what I am after!
I have to retool a web application for our vendors and part of that requires restricting content on a vendor by vendor basis. Looking at ASP.NET (MVC) this seems easy enough using the built in Authorization Filters and the IPrincipal and IIdentity interfaces (I haven't used them yet, just reading, so I may be using these terms incorrectly!).
What I'm not interested in doing is writing all the code for managing users and roles. I would love to be able to assume all of this is done for me by a third party application, and my code simply specifies roles required.
Now, I'm not exactly sure the product I am after, or if it even exists. Is this a CMS? Right now our vendor site uses a very old version of DNN. Some of our existing custom code is written as a module within DNN. I am not interesting in this type of solution at all. I want to be able to build a standard ASP.NET webapp and not be tied to a certain vendor 'module' definition. It seems like this should be possible if the CMS / Portal implement custom providers behind the ASP.NET provided API's, yah?
The primary (only) customer here is developers, if that makes sense.
Notes:
I really don't need a full blown CMS, which is why I'm confused on what type of product to search for. Some CMS functionality might be nice, but the site is only for very specific vendor interaction that is going to be 95% custom.
I see that ASP.NET provies a website administration tool, and that is cool, but doesn't solve the public facing aspects of user interaction.
ASP.NET provides extensive membership and role management APIs that are pretty easy to work with since version 2.0. They are available in ASP.NET MVC. Probably they do not require much more work than you would do anyway for styling or other stuff. But since you don't want to do it anyway, you can use a simple Web form with a Login control in your MVC app and make routing ignore that path with:
routes.IgnoreRoute("SignIn.aspx");
Just drag a login control to SignIn.aspx as you would in any Web form app.