Overview
The Hive Membership & Profile Wrapper in Umbraco is the way in which we link an ASP.Net Membership Provider with our own additional data, which we refer to as
Profile data. When we query Hive for Users or Members we do this by querying the Hive Membership Wrapper. The resulting data is a combination of data retrieved from the ASP.Net MembershipProvider that is linked with the current Hive Membership Wrapper and any additional data that we've stored for the member inside of Hive.
This Hive provider URI is:
- security://users - For back office Users
- security://members - For Umbraco Members
Membership & Profile Entity
Creating an entity to be used by the Membership & Profile wrapper is easy. Any TypedEntity that inherits from 'Member' can be used for this purpose... or any Entity containing the required Membership fields:
MemberSchema.UsernameAlias
MemberSchema.PasswordAlias
MemberSchema.EmailAlias
MemberSchema.PasswordQuestionAlias
MemberSchema.PasswordAnswerAlias
MemberSchema.IsApprovedAlias
For example, a new User entity can be passed to the Membership & Profile Hive provider. Internally, this Entity will be used to create a new MembershipUser object in the ASP.Net MembershipProvider and then this entity will be persisted 'as-is' to the Hive profile store
(security://profiles). This same principle goes for updating an entity as well.
The Entity IDs
When the Membership & Profile Hive provider returns an entity, this entity is the merged result of the MembershipUser and the profile entity.
The Id of the returned entity is the MembershipUser's 'ProviderUserKey' for the referenced ASP.Net Membership provider. Before the Entity is returned from the Hive provider, a special field is added called: MembershipSchema.LinkedProfileHiveId which contains the Id of the Profile entity.
Relations
All relations for the entity are stored in Hive with the Profile entity since we currently must store relations between content objects, etc... in the same Hive provider. Because we are storing the relation information with the Profile entity, this means that if you use the API to lookup relations for the returned entity from the Hive Membership & Profile provider, you will need to use the HiveId stored inside the MembershipSchema.LinkedProfileHiveId field. OR, just query the relations attached to the entity itself.
Authentication
As previously noted, relation data is stored with the Profile entity, this means that the SecurityService will require the entity's profile Id (NOT its normal Id) to be able to look up what User Groups it belongs to. For this reason, the in the AuthenticationExtensions, when the UserData object is created to be stored in the authorization ticket, the Id is set to the profile id (MembershipSchema.LinkedProfileHiveId)
Transactions
This Hive provider does support transactions, it does this simply by queuing callbacks, one that is executed immediately and returns a Unit Of Work (without a using clauses/non-disposed) and a 2nd that passes in the UOW (the 2nd callback does NOT Complete() the UOW. Then the transaction ensures that all UOW's are completed and disposed.
Schemas
This Hive provider does
NOT support querying schemas. This is because it doesn't actually store anything itself, it simply passes off storage to its referenced ASP.Net MembershipProvider and the profile Hive provider (
security://profiles)
Therefore, you cannot use this Hive provider to query for the 'User' schema, you must use the security://profiles Hive provider to do so.