leepeuker / movary

Self hosted web app to track and rate your watched movies
MIT License
388 stars 14 forks source link

Add API endpoint for retreiving an auth token #575

Closed JVT038 closed 6 months ago

JVT038 commented 7 months ago

This PR adds /authentication/request-token where an HTTP POST request should be sent.

It also adds a new header, X-Movary-Client, which allows the backend to distinguish the default Movary frontend from any 3rd-party apps that may want to use Movary's authentication.

This is important, because if it's just a 3rd-party, Movary will only return the token in JSON format while if it's the Movary frontend, the backend will return a HTTP 303 response. I stole this idea from the Plex API, which does the same, only with X-Plex-Product instead.

Additionally, I have added two columns to the user_auth_tokens table containing the Device Name (aka the value from X-Movary-Client) and the user agent string from the HTTP request. This allows us to add a new feature in the future, where the users can see all the tokens / devices and invalidate any token / authorized sessions. The user can see which token belongs to which app and which user agent was used to request the token. Maybe we should store the IP as well? And maybe another column containing the date that the token was last used.

Anyway, the default client name for the Movary frontend is 'Movary Web'.

The login process for the current Twig frontend has already been migrated from the old web endpoint to the API. It no longer works with the POST form, but instead JS is used to send the POST request; this is to allow a smooth transition to a TOTP form if it's necessary.

Also, the verification of the TOTP code has been moved from the TwoFactorAuthenticationController to the new API AuthenticationController. I did this because now the user can log in with the TOTP code with one HTTP request, instead of two different requests. The 2FA controller is still used for enabling / disabling the 2FA though.

Part of #572

JVT038 commented 6 months ago

@leepeuker I think it might be better to return a HTTP code 200 instead of the redirection to 303, because the clients should decide what to do when the authentication token is returned, not the server. This applies to the official web client as well