Table of Contents

Class DefaultUserService

Namespace
Tharga.Team.MongoDB
Assembly
Tharga.Team.MongoDB.dll

The standard user service, storing DefaultUserEntity users. Register it and write no user storage code at all.

public class DefaultUserService : UserServiceRepositoryBase<DefaultUserEntity>, IUserService, IUserCacheInvalidator
Inheritance
DefaultUserService
Implements
Inherited Members

Remarks

Everything stays overridable. Derive from this to change how a user is built from their claims, or how their key is generated. Use UserServiceRepositoryBase<TUserEntity> directly when the user entity needs properties of your own.

Constructors

DefaultUserService(AuthenticationStateProvider, IUserRepository<DefaultUserEntity>, ILogger<UserServiceBase>, IIconStore) 

public DefaultUserService(AuthenticationStateProvider authenticationStateProvider, IUserRepository<DefaultUserEntity> userRepository, ILogger<UserServiceBase> logger = null, IIconStore iconStore = null)

Parameters

authenticationStateProvider AuthenticationStateProvider
userRepository IUserRepository<DefaultUserEntity>
logger ILogger<UserServiceBase>
iconStore IIconStore

Methods

CreateUserEntityAsync(ClaimsPrincipal, string)

Builds the stored user the first time somebody signs in.

protected override Task<DefaultUserEntity> CreateUserEntityAsync(ClaimsPrincipal claimsPrincipal, string identity)

Parameters

claimsPrincipal ClaimsPrincipal
identity string

Returns

Task<DefaultUserEntity>

Remarks

EMail falls back to "unknown" rather than throwing: the property is required, and an identity provider that returns no email address should not stop somebody signing in over a field that is only ever displayed.

GenerateUserKey()

The key a new user is stored under. Override to use a format of your own.

protected virtual string GenerateUserKey()

Returns

string

Remarks

Matches how team keys are generated, which TeamServiceBase has always owned. Until this existed the toolkit generated team keys itself but left user keys to the host, so every host invented its own format for one half of the same model. Virtual because the format is a legitimate host choice, unlike the rest of building the entity.

Not uniqueness-checked against the store, unlike the team key: a user is looked up by Identity, and the key is an opaque handle rather than something anyone types.

Edit this page