You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Introduction
As detailed in the recent Lemmy announcement some changes are required to how authentication works in v0.19.0 and beyond
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.The text was updated successfully, but these errors were encountered: