 |
|
|
Joined: 3/22/2006
Posts: 12
|
|
|
DNN 4.3.4 Membership Provider model
Working with DotNetNuke 4.0.3, I developed concrete Asp.Net membership providers. Membership, Roles and Profile, all interfacing our own application. Wanting to use the new functionality in DotNetNuke 4.3.4 regarding profiles etc, we just upgraded to that version. Reading through the new documentation regarding the new provider layers "Abstracting the Membership and Profile Components _3.3_.pdf", "Enhancing Membership _3.3_.pdf", "Enhancing Profile _3.3_.pdf" and "Enhancing Roles _3.3_.pdf" I like what I read! You are doing a very good job here, and this is exactly what we need to be able to do what we want with DotNetNuke!
According to the specs, as I understand it, there should be 3 concrete membership implementations all interfacing with the AspNet provider layer. AspNetMembershipProvider, AspNetProfileProvider and AspNetRoleProvider. These 3 should be configured as default, hence making our AspNet providers work. Also, there should be, or plans for, 3 concrete implementations interfacing only with DNN. DNNMembershipProvider, DNNProfileProvider and DNNRoleProvider.
However, after some browsing of code, and testing our concrete provider implementations, it comes to my attention that the practical implementation here isnt according to the specs. Or maybe just not 100% finished yet? As far as I can tell, there is an AspNetMembershipProvider, but no DNNMembershipProvider. Thats ok with me, since the AspNetMembershipProvider is what I need. But when looking at the Roles and Profile providers, I can not find AspNetRoleProvider and AspNetProfileProvider! There seems to only exist providers accessing DNN here, namely DNNProfileProvider and DNNRoleProvider.
Specifically what I need is a working AspNetProfileProvider, that does what the specs say, so my AspNet concrete implementations that interface our application will work. Question is, does these classes exist somewhere? Are they planned for the future? Or is this something I need to develop myself?
My other option here ofcourse is to create my own DNN provider implementations using the new provider layer, and leave the AspNet providers behind, but I would rather not do that seeing that we spent so much time on developing those! Ofcourse this might be the next step anyway, but not something we can do now!
Anyone here can provide me with info about the missing AspNetRoleProvider and AspNetProfileProvider?
Thanks in advance!
|
| |
|
|
 | |
|
|
Joined: 3/22/2006
Posts: 12
|
|
|
Ok, been a few days, a few people have read my post, but still no answer to my questions here.. I thought id update on my progress, aswell as state some new questions need answering.
Iv been researching how these providers actually work, in order to decide which method I should use to implement my own providers. There are a couple of issues Iv come across so far, and I still cant decide what method to use, and the option I see atm isnt a good one imo.
In the 4.0.3 version of DNN, the version I originally developed my MS provider level concrete implementations, there was a "Lazy" synchronization between the provider user database and the local DNN user database. This was according to the documentation provided in that version. This new implementation is ofcourse a next step, and what I think a correct one, to replace this old "Lazy" synchronization. What this old lazy synch allowed for was for the user to only exist in the "Global Data Store" and at the time of login, the user was synchronized to the "Local DataStore". However, in this new version, that is not the case. From what I understand after reading a comment in the code, that is done intentionally:
Quote:
'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
This means that the user can not be created using the admin panel created by Microsoft, or whatever global database the provider is using. Even 2 DNN installations sharing a Asp.net provider database isnt possible! As I see it, this is a break of compatibility between the 2 DNN version. This, even though the spec documents mentioned earlier state that the AspNet provider is made default for backward compatibility. Between these version, this is a major step backwards. However, sometimes u need to take a step back to move forward, as the intention of this whole change very likely is in the first place. But that makes me wonder yet again if this is the full implementation, or if this isnt completely finished yet? And if not, whats the time frame for it to be?
Anyway, after reasearching some more, my first plan was to try to implement my own DNN concrete providers. To me it seems that the DNN provider implementation does alot of assumptions that make it only work with the local DNN database. For instance, the GetUser method has a UserId parameter of type Integer. In my global database, there are no UserId. And even if there was one, there's no saying it must be of that type. This suggests to me that the DNN provider model is tightly coupled with the DNN local database, which to me ruins the the provider model here. This to me suggests that should I implement my one concrete providers here, these need to handle the local DNN database aswell. Is that right?
I really need answers to my questions here, and I cant find any more information about this anywhere. I would like to avoid a 3rd rewrite of my code when the next version of DNN is released, so Id like to know what the plan for DNN is here so I can atleast make it open for the future changes.
Thanks in advance!
|
| |
|
|
| |
|
|
Joined: 2/12/2006
Posts: 20
|
|
|
Agreed, there is some limitations with the provider model.
The DNN Providers should have at least inherited from the Microsoft Providers. I think that would have been the best solution. Any custom dot net nuke stuff could then be added to the DotNetNukeProviders.
Any Custom written providers would then inherit from the DNN Providers, that way these providers could be used by all the Microsoft controls and the DNN controls etc...
As far as I can tell your only major problem is that your DB doesn't use int's as keys, you may have to implement some kind of joining table, or just add the int as a key to your current table. and unfortunately re-write your code, or at least cut and paste and rewrite a bit to make it work.
Even 2 DNN installations sharing a Asp.net provider database isnt possible!
This statement isn't true however. If your provider and config file is configured to use the same DB and tables, this is possible. It depends how you write your provider.
I've implemented this feature (finally) and while there are still a few issues from DNN, It works Ok.
Maybe there is a reason why inheriting from the Microsoft Providers wasn't done. I'd like to know what it was if there was one.
|
| |
|
|
| |
|
|
 |
Joined: 4/5/2003
Posts: 4377
|
|
|
Actually, to inherit from the asp.net concrete providers would be a fundamental mistake. Doing this is the exact opposite purpose of the provider model. We originally (DNN 3.0) wrote DNN to conform to the Asp.Net concrete Membership Services providers (this is the roles, membership, profile all together). Doing this we created issues because DNN had its own ways already. This limited the ability for others to create their own custom concrete providers, which is part of the reason this was changed in the x.3.x base.
The abstract provider was re-written to handle more than the asp.net concrete implementations, but re-doing the abstarct forced us to re-do the asp.net concrete versions. When doing your own concrete providers, you need the ability to use your own datastore items including tables. If you look closely, you will see that the DNNMembership provider is basically the asp.net concrete version and uses the same datastore. The DNNProfile provider, however, uses its own data store and is not dependant on the asp.net tables. This adheres to the provider model. (In both cases)
The datastore problems seen with the aspnet providers are not one which dnn can change. These tables are provided by MS and must NOT be altered by DotNetNuke. (Otherwise we are destroying their concrete provider and making our own, which goes against the original purpose of Member Role).
If you guys have more specific questions, I would be happy to answer when I have a few free moments so please use this thread to do so. Just an FYI, we collected several use cases prior to creating this re-write and as someone who tends to push DNN to its limits, I have yet to find an issue here.
|
| |
|
|
| |
|
|
Joined: 3/22/2006
Posts: 12
|
|
|
Ok, seems I got to explain myself a bit better! And maybe be more specific, although that can be hard sometimes when talking about abstract stuff, hehe..
I completely understand the difference between the Asp.Net provider layer and the DNN provider layer. Both have their reasons to exist in this implementation. Ofcourse the DNN provider layer shouldnt be inherited from the Asp.Net one, that would infact defeat its purpose. However, I do believe it should be less coupled with the DNN local store.
"Even 2 DNN installations sharing a Asp.net provider database isnt possible!" - I still do believe this is true, using the concrete implementation that are shipped with DNN 4.3.4. To clarify, what I ment by "Global database" was sharing the database in the Asp.Net providers, not the DNN providers. My point was that this *did* work in 4.0.3, hence compatibility with that version is broken. Example:
If you configure 2 DNN sites to use the same global database for the Asp.Net membership provider (still seperate local stores) , and try this scenario:
1. on DNN site A, create a user.
2. on DNN site A, login as that user. Works fine.
3. on DNN site B, login as the user created on site A, you will get access denied.
This is simply because there is no "lazy" sync of global users in DNN 4.3.4, as existed in 4.0.3. If the user doesnt exist localy in DNN site B, it will never be validated with or fetched from the global database.
Another example would be if I made an LDAP Asp.Net provider. The organization have an LDAP store, and wants the users created in that store to be able to log in to the DNN site. However, the users created in the LDAP store would not be able to log in to the DNN site, because the users doesnt exist in the DNN local store. This again assuming I was using the DNN AspNetMembershipProvider configured (default).
The "Int" example refering to the coupling problem with the DNN providers was just one example. The way to handle this is to create a local data store for each concrete implementation I make of the DNN providers. An example would be to create an LDAP implementation, and in that implementation also maintain a local database because the LDAP doesnt contain Integer userId's. Doesnt this defeat the purpose of the provider model? Or is enforcing to maintain a local data store by design? I would suggest making the DNN provider model less coupled, more open and flexible, and hence making it easier for users to implement their own concrete providers.
I would also think that the lack of the AspNetProfileProvider in this version is a compatibility break between 4.0.3 and 4.3.4. Simply because in 4.0.3 I can actually use what Asp.Net profile provider I like, but in 4.3.4 that simply isnt possible since no call is made to the Asp.Net provider layer at all. Specifying an Asp.Net profile provider in web.config simply doesnt have any effect at all. Isnt this what the DNN provider implementation AspNetProfileProvider is for, the class that the documentation mentions, but doesnt exist? I cant find it anyway. Same goes for the role provider.
Ok, to sum up the questions I have in these posts that I need answering:
a) Since the "lazy" synch of global and local database doesnt exist in 4.3.4, but existed in 4.0.3, and semingly by design, what is the plan for the future here in DNN?
b) Are there any plans for future changes and enhancement in the DNN provider model? Maybe to solve the tight coupling with the local database?
c) AspNetProfileProvider - In the documentation this one is mentioned, but I cant find it. Does it exist?
d) If there is no AspNetProfileProvider, is there a plan for one in future DNN versions, as mentioned in the documentation?
|
| |
|
|
| |