Introduction
As detailed in the recent Lemmy announcement some changes are required to how authentication works in v0.19.0 and beyond
Authentication
Previous Lemmy versions used to take authentication as query/post parameters. This is insecure and unnecessarily complicated. With 0.19, the jwt token can be passed either as cookie with name auth, or as header in the form Authorization: Bearer .
A major advantage is that this allows us to send proper cache-control headers, with responses to unauthenticated users being cacheable. It also prevents token leaks in web server logs. The login and registration endpoints attempt to set the cookie automatically. If that is supported on your platform, you don’t have to worry about the authentication token at all.
In order for your client to be compatible with both Lemmy 0.18 and 0.19, you should send auth in both ways. Meaning with each API call, send the old auth query/post parameter, as well as the new header or cookie.
A few PRs detailing these changes:
LemmyNet/lemmy#3725
LemmyNet/lemmy#3926
LemmyNet/lemmy#3946
LemmyNet/lemmy#3982
Requirements
The APIClient needs updated to start sending the authentication as detailed above. We should continue to send the old parameter for now and remove it once we see the majority of instances upgrade to this version.
Introduction
As detailed in the recent Lemmy announcement some changes are required to how authentication works in v0.19.0 and beyond
Requirements
The
APIClientneeds updated to start sending the authentication as detailed above. We should continue to send the old parameter for now and remove it once we see the majority of instances upgrade to this version.