Got it! Working own provider, and passwords do not have to contain garbage!

Home ›

ASP.NET Forums » General ASP.NET » Security » Got it! Working own provider, and passwords do not have to contain garbage!

Shortcuts

Previous Next

Got it! Working own provider, and passwords do not have to contain garbage!

Rate It (1)

Last post 09-15-2008 12:32 PM by guru_sarkar. 28 replies.

Sort Posts:

Got it! Working own provider, and passwords do not have to contain garbage!

04-20-2005, 10:10 AM

Contact

197 point Member
tomaszwaraksa
Member since 03-10-2003, 2:26 PM
Eindhoven, Netherlands
Posts 36

Follow those steps:

1. Equip your database with stuff needed for Membership services to work, by running the aspnet_regsql.exe wizard (to be found in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215 folder). Make sure that local ASPNET account is a database user and has access rights to this database

2. Add this section in web.config file, under the root node - it defines a connection string to the database above:

3. Define your custom role manager, responsible for role management, which makes use of the database above, by adding this stuff in web.config, inside <system.web> section:

<roleManager enabled="true" defaultProvider="DefaultRoleProvider">
      <providers>
        <add name="DefaultRoleProvider" type="System.Web.Security.SqlRoleProvider"
             applicationName="/"
             connectionStringName="LocalSqlServer" />
      </providers>
    </roleManager>

4. Define your custom membership provider, responsible for handling user accounts etc., by adding this stuff in web.config, also inside <system.web> section:

In points 3. and 4. note that we refer to the previously defined database connection via connectionStringName property.

Finally, in point 4. we've got those 3 properties at the end, which make the password requirements relaxed.

good luck!

Tom

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-25-2005, 12:23 PM

Contact

4,773 point Contributor
yaip
Member since 10-27-2003, 2:29 PM
Los Angeles, CA
Posts 1,145

In point 4, it tells me Attribute not defined for:

connectionStringNames,applicationName,description, etc.

What am I doing wromg?

Thanks
I love computers because: MY WISH IS THEIR COMMAND :)

<Website>
<Gadget>

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-26-2005, 1:11 PM

Contact

15 point Member
carlmeis
Member since 05-13-2004, 2:59 PM
Posts 3

Thank you this was a life saver.

I hope someone writes a better Web Admin utility because the one in VS Beta2 stinks of dead fish!

Carl

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-26-2005, 2:19 PM

Contact

4,773 point Contributor
yaip
Member since 10-27-2003, 2:29 PM
Los Angeles, CA
Posts 1,145

Couldn't agree with you more. It would also be very convenient if they provided a utility to migrate from Beta 1 to Beta 2.

Thanks
I love computers because: MY WISH IS THEIR COMMAND :)

<Website>
<Gadget>

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-26-2005, 5:00 PM

Contact

4,773 point Contributor
yaip
Member since 10-27-2003, 2:29 PM
Los Angeles, CA
Posts 1,145

I am really in trouble. I had to run aspnet_reqsql -R all -E -d myDB to unregister my database. Then I re-registered it using aspnet_regsql and now when I start ASP.NET Configuration Manager and click on the Provider tab, I don't see it. I just see ASPNetSqlProvider. Crying [:'(]

Thanks
I love computers because: MY WISH IS THEIR COMMAND :)

<Website>
<Gadget>

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-27-2005, 4:22 PM

Contact

100 point Member
bwinfrey
Member since 04-21-2004, 3:46 PM
Posts 20

Thanks for the post. I did not have to do step 1 though.

B

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-28-2005, 8:21 AM

Contact

197 point Member
tomaszwaraksa
Member since 03-10-2003, 2:26 PM
Eindhoven, Netherlands
Posts 36

Automatic unregistering of the databases, which have been equipped with Membership data with Beta1 tools, didn't go good here at my place... I had to manually remove all the database objects related to Membership services - all tables that started from aspnet_, also proper views and stored procedures. When removing tables, you'll get few errors, as they're dependent on each other (foreign relationships). You either have to delete them in particular order, or - as I prefer - use brute force method, just delete them few times (exactly 3) until they're all gone.

After that I re-registered my databases with aspnet_regsql tool from Beta2, which went smooth and fast, then modified web.config configuration files according to my comments above - and it's now all ok. Well... in Visual Web Developer, when opening the web.config file I still see some underscores - apparently the schemas for validating of web.config file are not in sync with what can physically be placed there - but that's just an annoyance, does not stop things from working.

Membership providers configuration - the other way

04-28-2005, 8:49 AM

Contact

197 point Member
tomaszwaraksa
Member since 03-10-2003, 2:26 PM
Eindhoven, Netherlands
Posts 36

...and there is an alternative to that pretty crappy webadmin application. If you go to IIS management console (Control Panel/ System Administration/ Internet Information Services), and open the properties of your virtual directory, there you should see an extra tab: ASP.NET.

In first instance it allows to select the version of .NET framework on which the web application is intended to run. Further, after clicking the "Edit Configuration" button, we see amongst others the whole goodness related to autorization and authentication services!

Now, I only noticed another problem related to the infamous Beta1->Beta2 leap... Namely, after installing Beta2 that ASP.NET tab, already present in Beta1, is gone. It's again so that some stuff is not properly removed/unregistered when Beta1 is uninstalled. To fix it:

0. Close IIS management console if you have it now open.

1. Delete registry keys responsible for enabling this extra tab, that still refer to a non-existent Beta1:

   HKEY_CLASSES_ROOT\CLSID\{7D23CCC6-A390-406E-AB67-2F8B7558F6F6}
   HKEY_CLASSES_ROOT\CLSID\{FD5CD8B1-6FE0-44F3-BBFB-65E3655B096E}
   HKEY_CLASSES_ROOT\CLSID\{FEDB2179-2335-48F0-AA28-5CDA35A2B36D}

The easiest would be just to find those guids via CTRL+F...

2. Go to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215 folder

3. Re-register .NET 2.0 into IIS, by executing the command

aspnet_regiis.exe -i

4. Open IIS Management console, go to virtual directory properties, now the tab is visible!

Tom

Re: Membership providers configuration - the other way

04-28-2005, 12:12 PM

Contact

4,773 point Contributor
yaip
Member since 10-27-2003, 2:29 PM
Los Angeles, CA
Posts 1,145

I have developed quite a few pages in Beta 1 and now I have "migrate" them to Beta 2. There doesn't seem to be an easy step for this. If not, I'll have to visit each and every page Sad [:(]

and redo them to conform to Beta 2. If anyone has any "tricks", please post them.

Will I have to go thru' this again when MS comes out with "go-live" version?

Thanks
I love computers because: MY WISH IS THEIR COMMAND :)

<Website>
<Gadget>

Re: Membership providers configuration - the other way

04-28-2005, 12:14 PM

Contact

100 point Member
bwinfrey
Member since 04-21-2004, 3:46 PM
Posts 20

I followed the steps listed, but still no tab. Are there minimyum requirements as to version?

Thanks.

Re: Membership providers configuration - the other way

04-28-2005, 7:49 PM

Contact

3,639 point Contributor
rmprimo
Member since 02-24-2003, 12:25 PM
Posts 731

You mean you didn't do a clean install? You have more guts than I do.

If any of the dev teams had to do their own uninstalls they would have more sympathy and make sure the software comes off clean.

But, reality as it is virtual server or preinstalled OS on mirrored cheap drives is the way to go. And I don't dare even save favorites urls on these machines, so if I had to, I could bail out in 30 seconds flat.

As far as I am concerned the biggest virus in the last year has been SSE.

Rob.

Regards,

Rob

Re: Got it! Working own provider, and passwords do not have to contain garbage!

04-28-2005, 7:58 PM

Contact

3,639 point Contributor
rmprimo
Member since 02-24-2003, 12:25 PM
Posts 731

see this post about the squigglies - it is just an inaccurate schema issue.

http://forums.asp.net/907536/ShowPost.aspx

I can understand no intellisense, no design tool but why no plain old CHM file detailing each element in the config "DOM". If they can't automate it at least document it.

Why didn't you just drop the whole db?

Rob

Regards,

Rob

Re: Membership providers configuration - the other way

04-29-2005, 1:22 AM

Contact

100 point Member
bwinfrey
Member since 04-21-2004, 3:46 PM
Posts 20

I agree SSE is S#$T -- I don't like it at all. The idea is very interesting. But as is usual it may have been (will be) released before it is completed.

If the dev team's QAstaff had to deal with these issues along with lack of docs it would be on the cutting room floor.

Re: Membership providers configuration - the other way

04-29-2005, 4:21 AM

Contact

197 point Member
tomaszwaraksa
Member since 03-10-2003, 2:26 PM
Eindhoven, Netherlands
Posts 36

Well, did it on Win2K Professional, Server and XP Pro - all just fine! As told before - deleting the registry entries (of course after previous uninstall of Beta1) responsible for those extra property pages, and re-registering the ASP.NET 2.0 into IIS was enough!

I guess you're looking for the tab in the right place?

;-)

Re: Got it! Working own provider, and passwords do not have to contain garbage!

05-02-2005, 3:32 PM

Contact

332 point Member
miriv365
Member since 06-30-2003, 3:26 PM
Houston, TX
Posts 76

Ok I was having issues with this, and your post helped a lot. I do have one slight issue.

If I use the following as my connection string in the web.config(as listed above), everything works fine:

<add name="LocalSqlServer" connectionString="Server=(local);Integrated Security=SSPI;Database=aspnetdb"/>

However, if I switch from Integrated Security to the following, it errors out- I have verified that the sql server is set up for mixed mode authentication, and I have verified that the information in this string works correctly by testing it when trying to connect using Query Analyzer.

name="LocalSqlServer" connectionString="Provider=SQLOLEDB.1;Password=****;Persist Security Info=False;User ID=***;Initial Catalog=aspnetdb;Data Source=*****" />

Basically the error says I can't connect to the database. Can anyone with fresh eyes point out what I could be doing wrong?

Page 1 of 2 (29 items) 1 2 Next >

RSS Available