In my previous Blogs on this topic I have described some of the major new enhancements coming for Membership/Roles/Profile. This blog is a miscellany of new features/changes.
New Profile Storage
Many of the enhancements in this release are related to extending the flexibility of the Profile, and as a result of these enhancments we have found that we have outgrown the usefullness of the aspnet_Profile table and its Text Blob storage of profile information.
We have therefore created a new table UserProfile which contains a single profile property per row:
- ProfileID
- UserID
- PropertyDefinitionID
- PropertyValue
- Visibility
- LastUpdatedDate
In addition we have created upgrade scripts to extract the existing profile data from the Text Blob and save it in this new table.
This will then allow us to support the new Profile enhancements, as well as provide an easier mechansim to allow Admins to do Data Mining on the Profile data.
Elimination of Reliance on HttpContext
Another area that has been causing Administrators and Module Developers grief, is the reliance of the aspnet implementation on HttpContext (ie you must have a Context to manipulate the Membership API). This was due to our implementation of the aspnet modules in an attempt to virtualise users between portals.
However, we have decided that the problems with this approach far outweigh the benefits of vitualisation (users are virtualised in our own UserPortals table anyway).
As a result, in the next release we will set a fixed Application Name "DotNetNuke" and update all existing users to this new mechanism.
Use of ReturnUrl in SignIn
In some modules, a user may be redirected to sign in when they try to attempt to do something that requires more permissions than they have.
Currently, after sign in they are redirected back to the page they cam from (but not neccessarily to the exact location within the module)
By storing the returnUrl and redirecting the user back to that url, the user will return to the exact location that redirected them.