From: SAL on 5 Jan 2010 12:41 Hello, We are currenlty using FormAuthentication (FormsAuthentication.SetAuthCookie) to log users into our web apps. We are currently using the aspnetdb and the SqlMembershipProvider for role and user management. We are using VS2008, SQL Server 2000. My question and problem is this. SetAuthCookie uses the username to set the authentication ticket and log the user in. We need to expand the schema slightly and include a new field in the database so I'm wondering if there's a way I can get the User's id from the database and use that rather than the user name to SetAuthCookie. The problem being that the user's username is not going to continue being unique and the user's UserId will be. What does SetAuthCookie user to do its magic? Is it using the SqlMembershipProvider to do this? And, if so, do I need to implement a custom provider to make it work slightly different? I'm sure you can see I'm a bit confused so any help on this would be greatly appreciated. Thanks in advance SAL
From: Gregory A. Beamer on 5 Jan 2010 13:41 "SAL" <SAL(a)nospam.nospam> wrote in news:umNrB5ijKHA.5052(a)TK2MSFTNGP04.phx.gbl: > What does SetAuthCookie user to do its magic? It is a wrapper of the security bits. If you want to see all the magic, download Reflector from Red Gate and reflect over the method. You can drill down and see precisely what is going on. > Is it using the > SqlMembershipProvider to do this? The provider is how it hooks to the membership data store and is used in the process, but the actual moving bits are in the security classes. > And, if so, do I need to implement a > custom provider to make it work slightly different? That would be my first option, rather than rebuilding the entire security mechanism, which is what you have to do if you completely step outside of the box. Overriding some methods is a pain, so you end up using Reflector to guide your path (examing MS's code) or you Google and find a custom provider similar to what you are trying. > I'm sure you can see I'm a bit confused so any help on this would be > greatly appreciated. The membership bits are confusing once you step outside the box MS provides. Peace and Grace, -- Gregory A. Beamer (MVP) Twitter: @gbworld Blog: http://gregorybeamer.spaces.live.com ******************************************* | Think outside the box! | *******************************************
From: SAL on 5 Jan 2010 16:26 Greg, thanks for you reply. from what I can see, SetAuthCookie doesn't actually hook into the AspNetSqlMembershipProvider. I see it reading the Authentication section of the Web.Config file. At least I assume that's what it's doing when it makes the: RuntimeConfig.GetAppConfig.Authentication call. It does seem to expect an Authenticated username and in fact, you can just pass it any old gobbledegook as a user name and it will set the cookie accordingly apparently. So, this kind of brings me to believe what I may really need is a custom role provider and perhaps a custom membership provider. The custom role provider to override the IsUserInRole method. I need to consider one more field in this than the user's name and role. And the custom membership provider as it looks like I may need to override the GetUser.ProviderUserKey property so I can consider an extra field to retrieve the key. Does it sound like I'm on track here? Is this more work than a day or two you think? Just asking.... :) Thanks SAL "Gregory A. Beamer" <NoSpamMgbworld(a)comcast.netNoSpamM> wrote in message news:Xns9CF780D778FDFgbworld(a)207.46.248.16... > "SAL" <SAL(a)nospam.nospam> wrote in > news:umNrB5ijKHA.5052(a)TK2MSFTNGP04.phx.gbl: > >> What does SetAuthCookie user to do its magic? > > It is a wrapper of the security bits. If you want to see all the magic, > download Reflector from Red Gate and reflect over the method. You can > drill down and see precisely what is going on. > >> Is it using the >> SqlMembershipProvider to do this? > > The provider is how it hooks to the membership data store and is used in > the process, but the actual moving bits are in the security classes. > >> And, if so, do I need to implement a >> custom provider to make it work slightly different? > > That would be my first option, rather than rebuilding the entire > security mechanism, which is what you have to do if you completely step > outside of the box. > > Overriding some methods is a pain, so you end up using Reflector to > guide your path (examing MS's code) or you Google and find a custom > provider similar to what you are trying. > >> I'm sure you can see I'm a bit confused so any help on this would be >> greatly appreciated. > > The membership bits are confusing once you step outside the box MS > provides. > > Peace and Grace, > > > -- > Gregory A. Beamer (MVP) > > Twitter: @gbworld > Blog: http://gregorybeamer.spaces.live.com > > ******************************************* > | Think outside the box! | > *******************************************
From: Gregory A. Beamer on 5 Jan 2010 16:42 "SAL" <SAL(a)nospam.nospam> wrote in news:umHh02kjKHA.5608(a)TK2MSFTNGP05.phx.gbl: > Does it sound like I'm on track here? Is this more work than a day or > two you think? Just asking.... :) It is not that hard to write a custom implementation. I may be able to pull one up and post it somewhere, as I had to make it easy to have an admin change a user's password on an app that originally used the default SQL implementation. Only override what you need to change and let the rest filter down if you want the easiest go of it. I can't remember how long it took to customize ours, but I do remember completely defining the entire problem took more time than coding the implementation. You do have to change the web.config file once you are done, but that is well documented. Peace and Grace, -- Gregory A. Beamer (MVP) Twitter: @gbworld Blog: http://gregorybeamer.spaces.live.com ******************************************* | Think outside the box! | *******************************************
From: SAL on 5 Jan 2010 16:56
Thanks Greg. That's kind of what I was thinking too. It looks like I'm, likely, going to have to implement more than a couple of methods so that when a new user gets added/deleted, this new field will get added too and then deleted filtering by the new field, etc. I haven't looked at the Membership provider implementation yet but there is an MSDN sample for the roler provider and I think maybe for the Membership provider too. I bascially need the exact same functionality as that exists except that I need this new field to be considered to add users, get the roles users are in, get the UserId in the database etc. Once I have the UserId, well that's the primary key anyway soooo... I'll take a look. Thanks again. SAL "Gregory A. Beamer" <NoSpamMgbworld(a)comcast.netNoSpamM> wrote in message news:Xns9CF79F8FBA1ACgbworld(a)207.46.248.16... > "SAL" <SAL(a)nospam.nospam> wrote in > news:umHh02kjKHA.5608(a)TK2MSFTNGP05.phx.gbl: > >> Does it sound like I'm on track here? Is this more work than a day or >> two you think? Just asking.... :) > > It is not that hard to write a custom implementation. I may be able to > pull one up and post it somewhere, as I had to make it easy to have an > admin change a user's password on an app that originally used the > default SQL implementation. Only override what you need to change and > let the rest filter down if you want the easiest go of it. > > I can't remember how long it took to customize ours, but I do remember > completely defining the entire problem took more time than coding the > implementation. > > You do have to change the web.config file once you are done, but that is > well documented. > > Peace and Grace, > > -- > Gregory A. Beamer (MVP) > > Twitter: @gbworld > Blog: http://gregorybeamer.spaces.live.com > > ******************************************* > | Think outside the box! | > ******************************************* |