standardnotes / server

Server ecosystem for Standard Notes; fully self-hostable.
https://standardnotes.com/help/self-hosting/docker
GNU General Public License v3.0
249 stars 60 forks source link

/auth/login api no longer works #359

Closed Mikescher closed 1 year ago

Mikescher commented 1 year ago

Problem Description

It seems the /auth/login endpoint now always returns status 410 Please update your client application.
This is despite using the same API version (20200115) and no changes in the auth version (4).
The [https://docs.standardnotes.com/specification/auth] also does not indicate any changes.

My own Investigation

The root cause seems to be the !performingCodeChallengedSignIn check in SignIn.ts which was added on Oct 3 in this commit.
The request only suceeds if the previous request to /params contains a code_challenge and the /login request contains a matching code_verifier.

(I guess the only reason why I only encountered the problem now, is that I reused the same session since october...)

The class InversifyExpressAuthController defines different sets of endpoints for querying params+login (/params + /login) and (/pkce_params + /pkce_login). Only the second variant passes the required parameters through and are thus usable (if I see it correctly the /params, /login combination will always fail).

For whatever reason I don't seem to be able to call https://sync.standardnotes.org/auth/pkce_params (or .../pkce_login) from my application.
I always get the response "Cannot POST /auth/pkce_params".

The web-app does not use the routes as described in the documentation, but uses a completely different domain and API (https://api.standardnotes.com/v2/...), which then gets redirected to the real auth-server via the class ActionsControllerV2 (which then uses the "new" pkce_xxx endpoints)

Relevant tickets in other rprojects

Solution

I think the documentation at https://docs.standardnotes.com/specification/auth/ should be updated, because the currently described workflow does not work (at least I think so?).

And there should be some way to use the API without having to fall back to the (undocumented?) api.standardnotes.com endpoints.

Also it would be nice if such breaking changes were announced somewhere and implemented in a new api-version to ensure existing applications keep running.

 

PS:
It's pretty late down here, I hope there is at least some useful information in between my late night rambling :D

moughxyz commented 1 year ago

These docs are very outdated I'm afraid. Will take them down soon.

I'm not able to judge from the ticket if there was a particular bug you wanted to discuss, or just reporting the outdated documentation?

Mikescher commented 1 year ago

Well I guess the changed behavior is either a bug or a feature. Depends if it was intentional :D

My main question is what third-party clients should do now, that the documentation is outdated and no longer works.
Or does that mean that third party API usage won't be supported in the future?

Currently I changed the SN plugin in AlephNote to use the same endpoints as the web app (I reverse engineered the api and the code_challenge cryptography a bit...).
But I don't think this is really future proof - especially when the API can just change again

 

Anyway - Greetings and have a nice weekend ~ Mike

moughxyz commented 1 year ago

Imo building a third party client without using our SNJS library will be a bad idea, because with encryption, everything becomes much more complicated to do manually. Whereas SNJS will always be the up to date mechanism by which to develop clients. Of course this would mean your client would have to be JS based.