Jump to content

Topic on Talk:Requests for comment/SessionStorageAPI

401 errors specification

4
Pchelolo (talkcontribs)

During the RFC discussion User:Smalyshev (WMF) pointed out that the API specifies 401 responses while not providing any data regarding auth/autz. I think these parts of the spec should be removed - this is simply a storage of session data, it has no idea whether a particular operation with the session is authorized. I believe limiting access to Mediawiki would be done on the network/firewall level, so it's simply impossible for the service to return a 401. Auth/autz is beyond the scope.

EEvans (WMF) (talkcontribs)

Two things: First, I think there was some confusion during the IRC discussion with respect to matters of authn/authz. I know that at least some people where referring to this in the context of the service providing the means to authenticate and/or authorize Mediawiki users. So, to be clear (and for posterity sake): a status 401 here refers to session storage clients (aka Mediawiki) being unauthorized to read and/or write to session storage, and nothing more.

With that said (and this gets into implementation details we promised to omit from the RfC, but oh well...), something such as this, with the security implications it has, should leverage depth of defense wherever possible. We definitely do want to limit by firewall, but I think we should also encrypt and establish some trust mechanism (which means it is possible to raise a 401, even if it would be an error in our config for that to happen).

Mobrovac-WMF (talkcontribs)

I think it's good to keep it, as one might imagine a future integration or interaction with auth(n|z) mechanisms, but such a thing is out of scope here.

Pchelolo (talkcontribs)

And then nothing will prevent us from adding it back in. It's not a backwards-incompatible change. Having it here now only creates confusion imho

Reply to "401 errors specification"