Description
A common way to harden services exposed to the internet is to use mTLS. Such a setup requires clients to be in possession of a valid certificate in order to be allowed to communicate with the server.
This adds an additional layer of security comparable to using a VPN, e.g. preventing untrusted clients from abusing vulnerabilities in hosted applications. While the official Immich app already supports mTLS, it'd be great if ImmichFrame did so too, when it comes to querying Immich's API.
Use Case
Details
A common way to harden services exposed to the internet is to use mTLS. In a regular TLS setup, it is only the server which is in possession of a certificate, which it uses to prove to the client that it is who it claims to be. In mTLS, the client must also present a TLS certificate, deemed valid by the server, in order to be allowed to communicate with the server at all.
This provides an added layer of security, similarly to using a VPN, where e.g. potential vulnerabilities in a service's built-in authentication cannot be exposed by untrusted clients all over the web. Support for mTLS has been added to the official immich app ~two years ago. On the server side, this functionality is supported by the vast majority of reverse proxies, such as nginx, Traefik or caddy.
It'd be great if support for mTLS could be added to ImmichFrame, so that it can be used in conjunction with a such-secured Immich setup. To clarify this would be about ImmichFrame acting as a client towards the Immich API, and not about the ImmichFrame app when connecting to the ImmichFrame backend.
In the .NET world, this seems to be supported by instantiating one's HttpClient using a custom HttpClientHandler, on which one sets the ClientCertificateOptions and ClientCertificates properties.
Defining a custom handler is also supported by factories implementing IHttpClientFactory, although that seems to require a brief detour via a 'named' HTTP client.
Pre-Submission Checklist
Description
A common way to harden services exposed to the internet is to use mTLS. Such a setup requires clients to be in possession of a valid certificate in order to be allowed to communicate with the server.
This adds an additional layer of security comparable to using a VPN, e.g. preventing untrusted clients from abusing vulnerabilities in hosted applications. While the official Immich app already supports mTLS, it'd be great if ImmichFrame did so too, when it comes to querying Immich's API.
Use Case
Details
A common way to harden services exposed to the internet is to use mTLS. In a regular TLS setup, it is only the server which is in possession of a certificate, which it uses to prove to the client that it is who it claims to be. In mTLS, the client must also present a TLS certificate, deemed valid by the server, in order to be allowed to communicate with the server at all.
This provides an added layer of security, similarly to using a VPN, where e.g. potential vulnerabilities in a service's built-in authentication cannot be exposed by untrusted clients all over the web. Support for mTLS has been added to the official immich app ~two years ago. On the server side, this functionality is supported by the vast majority of reverse proxies, such as nginx, Traefik or caddy.
It'd be great if support for mTLS could be added to ImmichFrame, so that it can be used in conjunction with a such-secured Immich setup. To clarify this would be about ImmichFrame acting as a client towards the Immich API, and not about the ImmichFrame app when connecting to the ImmichFrame backend.
In the .NET world, this seems to be supported by instantiating one's
HttpClientusing a customHttpClientHandler, on which one sets theClientCertificateOptionsandClientCertificatesproperties.Defining a custom handler is also supported by factories implementing
IHttpClientFactory, although that seems to require a brief detour via a 'named' HTTP client.Pre-Submission Checklist
This is a feature request and not a bug report
I have checked for related issues and checked the documentation