I spent some time searching the forums to no avail, so forgive me if this has been posted elsewhere and analyzed to death.

Could someone explain to me why the MembershipProvider class does not include a USERLOGOUT function?  I can't fathom why the core team would not want to include such a function for non-ASPNET membership providers (or why the existing logout code isn't moved to such a function in the AspNetMembershipProvider).  As it stands, it seems that while it is trivially easy to inherit from an existing membership provider class to extend DNN membership functionality, it seems impossible to add any OnLogout code without modifying the core. 

I wanted to check here to see if I was missing something before I registered this oversight in Gemini.  Am I?

Brandon

Hi John,

Thanks for the reply.  My desire really isn't to FIND a function that I can call in order to log out a user, although it is interesting that there are no references to the logoff function you pointed out in the DNN code.  Why doesn't logoff.ascx use this function?

But back to my original question.  The provider model should allow a developer to replace the functionality that is within the domain of that provider.  With the membership provider, I can clearly create a new provider that handles membership in any way that I desire.  However, there is no way to extend or create custom logoff logic!  I can't extend the logoff function you pointed out without a core change.  Why bother with the provider model at all?

It seems to me that the logoff.ascx control (and any other code that logs off a user, if any) should be routed through the membership provider.  That way, if a developer desires to create custom behavior, s/he may do so.  Such is the intent of the provider model.

I guess what I would expect is that the UserController would contain a UserLogout function (Why doesn't it already?), and within the code of that class we would see something along the lines of:

memberProvider.UserLogout(currentUser)

... and the membership code could do whatever it desired.  Obviously, the AspNetMembershipProvider wouldn't need to do anything.  But that fact doesn't mean that DNN should ignore those developers with different membership requirements.

B