I want to add custom columns to some tables created by ASP.NET.
For example; I need to add two fields such as FirstName and LastName to the aspnet_Membership table.
I can add this directly by editing the table but;
Is this the right thing to do (I mean; extending the table directly) OR should I create a separate table and hold the extra user data, there?
How can I see these custom database fields as properties in code completion? example: membershipuser.FirstName;
thanks.
You would typically use profiles to store user related meta data. This requires only simple configuration and no custom provider implementation.
You should only ever consider custom implementation of the battle tested security related providers when you absolutely must.
here is a link to a fine example of implementing profiles in asp.net.
There is a nice library that provides you with custom membership and profile stuff.
http://altairiswebsecurity.codeplex.com/wikipage?title=Simple%20SQL%20Providers&referringTitle=Home
make a custom membership provider! this will give you the basic idea. just extend the existing asp.net membershipprovider
http://www.davidhayden.com/blog/dave/archive/2007/10/11/CreateCustomMembershipProviderASPNETWebsiteSecurity.aspx
you could also go with the membership provider starter kit if your app is MVC'ish at codeplex
http://mvcmembership.codeplex.com/
I recommend you to create a custom membership provider if your application requires features that go beyond the basics provided by the ASP.NET Membership Provider.
Related
Im looking for something similar to rails admin for asp.net.
Essentially I need to write an admin layer that allows most table data to be changed / searched etc.
I could generate basic scaffolding however I'm wondering if there is a free or commercial admin package that would give a nice UI admin interface to the data.
Ideally I need to be able to control and add logic to it also.
I create Ilaro.Admin and it is exactly what you looking for, but please keep in mind there are a lot of stuff to do.
Im really newbie with drupal 7 and I want to tests things with it:
I want to build a form page that will get information from users.
for example workes that input FIRSTNAME, LASTNAME ID, PHONENUMBER and etc.. after that they will submit and it will enter to the workers db.
as I mention im really newbie with drupal.
so first of all, where do I start? is form api is the best way to do it?
secondly, the system create the workers db or I need to create a new db and table?
Drupal has examples module that has lots of example for developers you can install it and check code how it, i think form_example it suite for you.
Why don't you use the standard Drupal Content Types. You can create a content type named worker and the have your workers add their info as you wanted.
To create your custom content type:
You can create your own custom content types by going to Menu >
Structure > Content types > Add content type
(admin/structure/types/add). You might do this as a way to organize
your content. For instance, you might have "Info" and "News flash" as
two simple content types on your site, rather than just using
"Article" for both.
Another alternative to use webform contributed module. It will give you the ability to create a from with fields of your choice.
Webform also provides few features out of the box you might need to use. Like; Limiting number of submissions and unique fields.
Finally, I'd suggest you can read Drupal concepts.
I am working with a site that needs to use two different asp.net profile providers. They are both added in the web.config and the properties of each of them are listed there as well. I run into a problem when I try to enable a property that has the same name in each provider. Comment one out, and the site will at least load. Leave both in, and I get an error like:
Item has already been added. Key in dictionary: 'myfieldname' Key being added: 'MyFieldName'
The properties are entirely different (different types even), but I am missing how I would allow both to be used.
There must be some way I am missing as this seems like it could be a common problem.
I've only ever implemented a single profile system with a Web Application project. With the Website template, the functionality is out of the box. Profiles allow you to store some extra information per user when using the ASP.NET membership system. Profiles are stored in the database automatically when we add this extra information to our web.config file.
It makes sense that there would be a clash if you are using profile properties with the same names - a possible solution would be to create your own table mapping - for example, give 'MyFieldName' an alias in the web.config but map it to the real property name in your code. Since much of the functionality is out-of-the-box with the website template, you may be limited in the amount of customization you can perform.
The following links may help:
http://code.msdn.microsoft.com/WebProfileBuilder
http://weblogs.asp.net/joewrobel/archive/2008/02/03/web-profile-builder-for-web-application-projects.aspx
http://weblogs.asp.net/jgalloway/archive/2008/01/19/writing-a-custom-asp-net-profile-class.aspx
I have an application which uses the built in ASP.NET membership provider. There are two roles (admin and staff). I want admins to be able to see a list of current staff, add or delete staff and reset passwords. So far I've found very little information, but Membership.Provider.GetAllUsers looks promising. Is there any way I could show the list in a GridView?
At minimum, I need to be able to add and delete users through the site.
For an extensive guide on using the Membership and Roleprovider in ASP.NET, see this tutorial: https://web.archive.org/web/20210513220018/http://aspnet.4guysfromrolla.com/articles/120705-1.aspx
Creating users programmatically is explained here: http://msdn.microsoft.com/en-us/library/d8t4h2es.aspx.
But really, MSDN is very complete on this subject. Just read the Introduction into Membership and follow the links. Everything you want is perfectly possible.
I found an excellent tutorial at https://web.archive.org/web/20211020111539/https://aspnet.4guysfromrolla.com/articles/052307-1.aspx which made the whole thing slightly less murky. A nightmare to implement but it's almost working. Thanks for the replies.
If you're using SQL Server, you can use the default SqlMembershipProvider class in System.Web.Security to perform the user management tasks you require. GetAllUsers() returns a string array, so you can databind your GridView to the result from this method to display a list of user names in your grid.
In ASP.NET what's the best way to do the following:
Show certain controls based on your rights?
For a gridview control, how do you show certain columns based on your role?
I'm thinking for number 2, have the data come from a role specific view on the database.
Instead of actually using roles to hide/show certain controls, I would suggest having another layer of permissions for each role and show/hide based on those instead.
That way you can redefine what permissions a role has and won't have to change your code.
Also, this allows you to make new roles in the future and just assign a set of permissions to the role.
As for controls, yes... I would just set the Visible property on the control based on the user.IsInRole("permissionname") value.
For grids I would do the same... set the Visibility of the columns to the IsInRole boolean value.
//Delete Icon Column
gridViewContacts.Columns[0].Visible = user.IsInRole("DeleteAnyContact");
I would make create your permissions in a very granular nature.. such as
ViewAnyContact
ViewOwnContact
EditOwnContact
EditAnyContact
AddAnyContact
DeleteOwnContact
DeleteAnyContact
Etc...
If you're going the role-based route, ASP.NET (since version 2.0) has had a variety of membership controls available which might help in this scenario. Assuming (and this could well be a faulty assumption) that you're using the in-box membership provider, you can actually use the LoginView control to get #1 handled.
The way it works is that the LoginView can use RoleGroups and their associated ContentTemplates to customize the view for the user based on role. This works seamlessly with the in-box membership provider; I believe if you build your own membership provider based on Microsoft's technology it will also work. (I haven't done this latter step.)
Conceivably, you could use it for #2, but it'd wind up with duplicated code and effort, which isn't my personal preference. I think your choice of using role-specific SQL views to drive that table may be better than this option. (There are other options as well, of course, which may be better.)
I will second Elijah Manor's recommendation of using permissions instead of roles. Generally, that's my preference as well. (And I was surprised to discover that the membership provider technology didn't go to that level.) In any permission-centric scenario, though, you will essentially have to roll everything yourself. (I've done this, and while it's very flexible, the code to secure any given page can get hairy.)
EDIT: I apologize; I meant to include a link for the LoginView control. DotNetJunkies has a tutorial on it.