This project provides
DanglHttpClient to easily interact with all Dangl web services.
To avoid TCP exhaustion,
HttpClients and derived types should always be used as singletons.
ITokenHandler is an interface that be be used to support the automatic
obtaining of Tokens and refreshing them. It can be configured to support either of
the functionalities or none at all. If none is supplied, by default a
is used that does not perform any operations.
It can be used, for example, in server backends that use the
If you want to act when a token is obtained or refreshed, you can use the
event on the
ITokenStorage is an interface that is used to store and persist tokens, e.g.
it could use the local app storage on a mobile app or the database in a server application.
It is used so that only tokens and not the full user credentials need to be stored.
By default, there's an
InMemoryTokenStorage for non-persisting use available.
This is a simple class that only keeps a reference to an
HttpClient. When the
is used, this class can be specified as a dependency to be able to have easy access via dependency injection to
a correctly lifetime-managed
FallbackHandler is a
DelegatingHandler that can be configured with multiple
baseUrls. If a request
is returning an error that can possibly be recovered from by pointing to a fallback, the request is sent again
to the next available fallback url.
AuthenticationHandler internally uses
ITokenStorage to append OAuth2 Bearer
authentication to whitelisted urls.
GzipHandler is an implementation of
DelegatingHandler that sends requests gzip compressed.
AddDanglHttpClient<T>() method can be used to register an
HttpClient with both an
FallbackHandler via the
Dangl.RestClient.Identity.App package contains a
DanglIdentityAppTokenHandler which can
be used in client-side applications, meaning applications that are distributed to clients. It offers
functionality to integrate with web apps that make use of the Dangl.Identity.Client.Mvc package to
delegate login to Dangl.Identity.
It works based on the passed-in
ITokenStorage and is safe to use as a singleton throughout the app lifetime.
While it is possible to instantiate this with username / email and password, it is advised that this is not done. A typical workflow in an app should be:
- On the login screen, ask the user to provide his credentials
- Perform a token-based authentication with the Dangl.Identity.Client.App package and store
the token in the used
- Let the
DanglIdentityAppTokenHandlerhandle only token refresh.
Alternatively, you can set the user credentials in the
DanglIdentityAppTokenHandler after instantiation via the
Assembly Strong Naming & Usage in Signed Applications
This module produces strong named assemblies when compiled. When consumers of this package require strongly named assemblies, for example when they
themselves are signed, the outputs should work as-is.
The key file to create the strong name is adjacent to the
csproj file in the root of the source project. Please note that this does not increase
security or provide tamper-proof binaries, as the key is available in the source code per