Safe Launcher Authorisation vs Not being logged in

What’s the current best way to check if a user is logged in vs an app auth being declined?

Currently, when not logged in, but trying to auth you get a 401: Unauthorised response, which is exactly the same as if the app was declined.

I’m interested to know if there’s a simple method for checking if a user is logged in right now? (So we can prompt them to log in).

1 Like

Currently you can’t tell from the outside. Overall our (HTTP)-Error-Codes are a bit cryptic and applied to broadly. We most obvious being a differentiation between launcher-side errors (like this one, generally in the 500-range) and client-side errors (in the 400-range). Like for this case, I’d say that 511 Network Authentication Required should be returned instead. Right now, it isn’t though.

We have a draft in the drawer to provide more specific codes and information, but that requires some bigger changes in the underlying things, too, and we aren’t sure yet whether we want to continue down that path.


Okay cool. yeh I thought it wasn’t strictly possible yet, but wanted to check.

For the mo, for any launcher checks I’ll perhaps just show a message of ‘ensure the launcher is running and you are logged in’ as a catch all.

Thanks, @ben

another thing, that perhaps might want it’s own thread… not sure:

Can we at some juncture get the full API errors displayed in the launcher?

I was thinking, short version as we have it, but click for full error? It could be quite useful for application debug, especially if we can display the key info nicely. Node debugging of fetch requests is less than fun…

1 Like

Just to say, the reason phrases can be changed within the specification. So, if there isn’t an appropriate code, an existing code can be used with a different reason phrase, e.g. 401 Unauthorised, 401 Invalid Credentials, etc.

“The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase’s, are presented below. The reason phrases listed here are only recommendations – they MAY be replaced by local equivalents without affecting the protocol.”