Open SoniEx2 opened 1 year ago
I'm not sure what you want here, but I guess the current design doesn't allow this as everything is done by the client side; the server doesn't do much except processing API requests.
instead of using an in-page login button, the browser can provide a standardized login button, using standard HTTP authentication (on pages with 200 response code, not 401).
this is only available in browsers that implement this optional part of RFC 9110, which are currently none of the major browsers. but the spec allows it.
it would not involve pop-ups or anything like that, but a button the user can click to trigger authentication. the nice thing is that it'd be consistent across websites and themes and whatnot.
I guess I get it, but currently the server doesn't really know whether the authentication has happened or not, it simply just sends the same template page to load the client for every URL (and then the client reads the URL to render the right page).
So currently it doesn't really make sense; the server sends the same response for every HTML page request regardless of the authentication, while per the spec the header indicates it "might affect the response", as you already noted.
Summary
In the interest of standardizing the concept of login across platforms, it'd be nice if misskey implemented RFC 9110 section 11.6.1:
"A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response."
This would provide similar benefits to e.g. IRCv3's SASL, sidestepping "oblique login button placement".