Hehe, im all ok, I like that I get some good responses here now. Now we just have to understand eachother better! Mind "just" haha..
The abstract provider is built the way it is to integrate w/ these DNN data store specific items. AT some point, there must be a way to 'bring together' these items as DNN must be able to extend the user, role, profile providers beyond what is available in the Member Role implementations. There is no difference here from how CS byTelligent does (in terms of general concept).
Im not sure I completely understand what u mean here, but im assuming that by "DNN data store specific items" you are talking about whatever database items, being it core modules or 3rd party, that is refering to a user. Specifically, by having a userId column in their table.
With that assumption made... I do see *why* its done this way, but for the provider abstract implementation to make assumptions like that regarding the concrete implementation's data store forces that providers datastore's schema to look a certain way. A schema that most often would already exist in the time of the programming of the DNN provider for it. I think logic like that is better placed in the app's core, and not in a data store specific provider layer. Like stated, if I was to make an LDAP provider (Or any other implementation where the already existing data store doesnt have a user identification value of type Integer), I can impossibly do that without maintaining a local data store aswell.
In order to explain the different problems I have we'v gone knee deep in different theoretical programming technieque's. That was not my intention. All I really need to know is your (DNN dev's) thoughts about, and future plan, was for this provider model, so I can make my implementation according to that. If this is the final version, so be it.
If you want 2 DNN installations to share the same user store, you need to do two things: Make use of object qualifiers, differing between your DNN installations. You also need to use the AspNET profile provider, and not the new default DNNProfileProvider. If you change this provider, you could theoretically integrate with other asp.net applications like Community Server, which also use this provider model and concrete provdier.
c - The code for this is part of the aspnet membership project. Provider.Membership.AspNetProvider. Since these are all the MS implementation, it was decided to group them as one codebase to keep the project number down at least a bit here. This means you point all your providers in web.config to this, you will be running the same stuff as in 4.0.3.
Im trying to understand what u mean by "the AspNET profile provider". Assuming you mean the AspNetProfileProvider the "Abstracting the Membership and Profile Components _3.3_.pdf" document talks about, I can not find it. Specifically, opening the 4.3.4 project source code, I can not find the AspNetProfileProvider class in Provider.Membership.AspNetProvider.
You discussion of your scenario is not clear to me, and I almost feel that you are talking about portals
To clarify, im not talking about portals! =)
To be clear here, if you have two dnn installs it will never be possible to run them from a seperate database from one another and share this aspnet membership base (unless you make core changes and add a connection string specifically to handle this). This is no different than any other aspnet application, the two applications have to use the same database to share this datastore data.
I am assuming you are talking about when using the aspnet default concrete implementations of the aspnet abstract provider. In 4.0.3, you could add a connection string and then set the connectionStringName attribute of the aspnet provider to the name of that connection string, and you could have the asp net provider access whatever datastore u choose. Even one "beloinging" to another DNN installation. And then, at login time, as stated in the "DotNetNuke Membership.pdf" document, there would occur a lazy synch.
You can currently use the aspnet membership in DNN and take advantage of Active Directory, this will 'sync' dnn user information up for you. This could easily be extended to add various options if one were so inclinded to do so. This would not require any changes from existing providers for Membership Services today.
WHen you are talking about the web.config provider changes, I want to make sure that you MUST set this prior to installation of your DotNetNuke site. I have changed the default profile provider prior to installation and seen this work 100% properly. I have also done this with the Membership Provider. You MUST remember, your concrete implementation must adhere to the abstract API to ensure this happens properly at time of install. Because you can change the profile provider to the aspnet one prior to install, there is no 'compatibility' break.
Yes, it would synch the users. Once, at install time. What about users created later in the AD? They would not be able to log in. The quote from the code again:
Line 1334 (or close) in Provider.Membership.AspNetProvider.AspNetMembershipProvider.vb:
'For now, we are going to ignore the possibility that the User may exist in the
'Global Data Store but not in the Local DataStore ie. A shared Global Data Store.
"Global Data Store" is refering to the AD here, and "Local DataStore" the DNN local database.
Ok, now I have another question for you. Is user synch of users at install time all that is intended? Isnt the intention by the provider model to be able to have a shared user data store?
If the answer here is that the users should only synch at install time, then I would think it a compatibilty break between 4.0.3 and 4.3.4, simply because the users were synchronized at login time (and other times aswell) in version 4.0.3. Thats a contrete way, although a bit simplified, of putting it anyway.
a - To understand what im refering to by "lazy" synch, read the document "DotNetNuke Membership.pdf" that was shipped with version 4.0.3.
b - Thats exactly what im doing. And there are problems with implementing that without maintaining a local data store aswell, as stated above.
c, d - See above. I cant find the class AspNetProfileProvider in the code anywhere. Iv searched for it using explorer and VS, but its just not there. Is the source code version iv downloaded incorrect/incomplete? Or maybe u can point me to it.
My solution to my problem for now has been to implement my own providers have been to literally copy the code of the Provider.Membership.AspNetProvider.AspNetMembershipProvider to then modify it to lazy synch the users among other smaller changes. Also, Iv copied and pasted the Provider.Membership.DNNProvider.DNNProfileProvider code, and done the same thing here and by that turning it into a AspNetProfileProvider. And then ofcourse I configure web.config to use these, and my concrete implementaions of the AspNet provider model aswell. Do I like to do it this way? Ofcourse not,
PS. Leafrink, I think your idea is interesting.