Return 401 if fun is 'grain.items' about salt-api

[whiteinge]

The external_auth section in the master config works on regular expressions so unless you have allowed access to a module named grain it will get stopped before attempting the execution. If you were to allow access to that (non-existent) module it will return '"grain.items" is not available.' as expected.

See ticket #59 which will make errors like this more obvious.

[PierreR]

Yep, thanks for the explanation.

It seems to me that the external_auth should make the difference between an authorization failure and a non-existent module. Then Salt-API would send 403 instead of 401 in case the authorization fails and a 400 or something when the request is invalid.

[PierreR]

Anyhow (it might be as well the job of salt-api to check if a module exists before calling external_auth), I cannot really understand why then host.list_hosts another non-existent module return 200

[pradermecker]

Forget about my last post. I had written host.* as external_auth ;-)
I still believe it is rather confusing to return 403 when a non-existent module does not pass authorization.

[whiteinge]

I hear you. The external_auth check happens on the master and the master doesn't know what modules are installed on each minion. We could make some educated guesses there, of course, possibly based on what modules are installed on the master or what the master knows from cached data from previous executions but they'd only be guesses. It is useful to think about though.

Ticket #59 should make this more obvious since you'll see the current user's permissions in the output from the 403 response (same as the output from the newly changed /login URL).

Another possible take on making this more user-friendly could be saltstack/salt#4352 so that typos in the external_auth config are caught early.