There will surely be more posts like this on this blog.
This one talks about the
- being a little overzealous with password security on a user group website
- applicationName element in membership provider config and
- intellisense in web.config.
Dumb thing #1: overzealous security!
I can't help it! I think a lot about security and write and teach it too. So of course I want to lock everything down as though it were the U.S. Dept of Treasury! And I did this to the members of the Vermont.NET website. Silly me! In the membership provider, you can choose between storing passwords in clear text, hashed or encrypted. Hashed is the most secure since it can't be reversed. If a user forgets their password, ASP.NET creates a new one and mails it to them (in clear text - uggh!). But the new ones are insane like:
#!E3@x*p?t or something similar - utterly impossible to remember. As existing members were quickly re-signing up to the new site, I got numerous complaints. So I changed the format to do encrypted. Digging in the database files, I could see that membership kept track of what method was used when the login was created so that it would use that method when the user logged back in. So existing users did not have to re-create their logins. However, because I changed the p/w retrieval mechanism it meant that "hashed pw" users would not be able to get their (or new) passwords back. Plus if they wanted to recreate their login in the new manner, I would have to delete their login so they could use the same login & email address again! I let them know and told them they can start from scratch now, or just let me know when they lose their password and we'll deal with it at that time.
Dumb thing #2: not learning about the all of elements of a configured membership provider.
An example of a membership provider from MSDN docs looks like this:
I was in the midst of moving from my hosted SQL2000 database to a new hosted SQL2005 database and had inadvertantly deleted the applicationName element from the above config.
I opened up the ASP.Net Web Site Administration tool and added my default users (me as admin and an anon user). But I couldn't log in and Membership.GetAllUsers returned 0 users.
I finally looked at the GetUsers sproc in the database and saw that ApplicationName was a required input parameter. So I fixed the config and my 2 users disappeared. Makes sense becasue they belonged to some NULL application. Therefore, I removed the applicationName element again so I could go and delete those users and then after fxing the config one last time, all was well again.
Later, I discovered that the default “\“ was causing problems for me as I went from my developer machine to my web host because membership was doing something like resolving to the virtual directory name, which was different in the two places. By configuring a real app name there such as “VTDOTNET“, I was able to clear up all of the confusion that the API was having.
More on customizing your membership provider...
Dumb thing #3: Wondering why I was so special that I could not get intellisense in web.config. It's one of the great improvements of VS2005. Heck I remember seeing demos of it at PDC03!
The secret is that ASP.NET does not seem expect you to use both the Web Site Admistration tool and manually coded web.config elements. When you use the WSAdmin Tool it adds a namespace to
<
configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
Removing the namespace (back to plain old ) brings intellisense back.
The admin tool will add it back in next time you go to use it, so just be persistent. Intellisense is a godsend (relatively speaking, of course) to web.config, so don't do without it if you don't have to!