BugNET

I downloaded the latest code from SVN and did see a new Membership provider where there is a new implementation of a custom membership user. The membership provider is creating a new CustomMembershipUser and populates some data from the profile. As same reason as my previous post http://bugnetproject.com/Forums/tabid... this is not a preferred way to handle the membership and profile concept, now there is a hard coded reference to the CustomMembershipUser object and I need to implement the ExtendedSqlMembershipProvider or at least inherit from it.

The preferred way is to handle the user and profile separate, create a MembershipUser object anytime you need access to the basic user information and create a ProfileBase object when you need the profile data. If you only need to get users email it’s much more overhead to load the profile.

If you insist to have a custom membership user object for easy access to information it’s much better if for example the ITUser class GetUser method creates the object and populate the profile data.

//Kalle

The membership implementation in BugNET is truely custom as you have no doubt noticed. On one hand, it is not portable or easily shared with multiple authentication providers but on the other hand the current implimentation provides referential integrity on the user tables to other records.

I wouldn't be so fast to completely rewrite the current implimentation. Obviously it depends on your situation which you require a shared authentication system. I supposed guids could be replaced with the username and contraints be put on the username field. If you ever had to change a username it would be a costly process though.

Like you said, if we use option 1 and use the user id GUID throughout the application it would be a lot less work and essentially a change to the application and stored procedures to switch the use of usernames to userid to be consistant throughout the application. The user id would be gotten from the user provider key so it would be pulled from the provider and not tied to BugNET.

I don't think its an easy change as quite a bit of sql code would have to be changed and the data layer. There are quite a few places in views etc that joins to the asp.net tables are done in which user names etc are done and would all have to be changed to use the provider as well. Ultimately it would be very easy to switch the provider after this is done though as BugNET would have no depencies on a specific user table etc.

Roles are not quite provider based either and very custom to bugnet. The default role provider falls down for our needs.