- Use AuthenticatonException to return 401
- Use SecurityException to return 403
- Update existing throws to throw the correct exception for the circumstance
This commit fixes the emby/user/public API that was returning more data
than necessary. Now only the following information are returned:
- the account name
- the primary image tag
- the field hasPassword
- the field hasConfiguredPassword, useful for the first wizard only
(see
https://github.com/jellyfin/jellyfin/issues/880#issuecomment-465370051)
- the primary image aspect ratio
A new DTO class, PrivateUserDTO has been created, and the route has been
modified in order to return that data object.
* Add analyzers to MediaBrowser.XbmcMetadata
* Enable TreatWarningsAsErrors for MediaBrowser.XbmcMetadata
* Add analyzers to MediaBrowser.WebDashboard
* Enable TreatWarningsAsErrors for MediaBrowser.WebDashboard
* Disable SA1600 in favor of CS1591
Analyzers are only run in debug build, so setting TreatWarningsAsErrors
for release build will catch the compiler warnings until we resolve all
analyzer warnings.
This reverts commit c230d49d7c.
This reenables an edge case where an admin might want to reset, with
the default auth provider, the password of an externally-provided
user so they could "unlock" the account while it was failing. There
might be minor security implications to this, but the malicious
actor would need FS access to do it (as they would with any password
resets) so it's probably best to keep it as-is.
Removing this in the first place was due to a misunderstanding
anyways so no harm.
Implements the InvalidAuthProvider, which acts as a fallback if a
configured authentication provider, e.g. LDAP, is unavailable due
to a load failure or removal. Until the user or the authentication
plugin is corrected, this will cause users with the missing provider
to be locked out, while throwing errors in the logs about the issue.
Fixes#1445 part 2
Pass back the Username directive returned by an AuthenticationProvider
to the calling code, so we may override the user-provided Username
value if the authentication provider passes this back. Useful for
instance in an LDAP scenario where what the user types may not
necessarily be the "username" that is mapped in the system, e.g.
the user providing 'mail' while 'uid' is the "username" value.
Could also then be extensible to other authentication providers
as well, should they wish to do a similar thing.
