* Revert "Verify auth in saltnado run (#32552)"
This reverts commit b19c5a5ce7.
* Call runner.cmd_async instead to enforce eauth
* Check for both token or user/pass before giving to Salt
* Remove comment as we're now enforcing auth here
* Lint and functionality fix courtesy of Mike P.
* Don't fail the whole request if there's an eauth problem
A preflight request send the list of headers of the final request
in a special header ```Access-Control-Request-Headers```.
The server must returns the list of allowed header in the special header
```Access-Control-Allow-Headers```.
This PR just returns the whole list of headers but may allow filtering of some
of them quite easily. I'm not sure to see how filtering how headers may
impact security, if anyone has some leads.
Login endpoint supported only application/x-www-form-urlencoded which may
be an useless limitation. This PR add support for more content-type,
JSON and YAML and every content-type supported by saltnado in general
as it uses the same deserialisation method than the lowstate deserialisation.
It currently supports 'simple' values like application/json, but Accept header
could also include more than one value with parameters
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1.
For example:
```application/json, text/javascript, */*; q=0.01```
This PR add support for multiple media_range in Accept header, support parsing
of parameter (like q=0.01) but discard them and finally iterate on
media_range and take the first compatible.
A more complete implementation may fully supports the RFC and support
q parameter and specific order of priority to find the most compatible
Content-Type but I don't think it's worth the pain.
If we want a better implementation, werkzeug has actually an implementation
http://werkzeug.pocoo.org/docs/0.10/datastructures/#werkzeug.datastructures.Accept.best_match.
It currently supports 'simple' values like application/json, but Content-Type
header could also includes parameter. See RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17.
When sending JSON from a browser for example, the Content-Type is
`application/json; charset=utf-8` and salt-api failed to detect JSON content.
The proposition is to use cgi.parse_header method (https://docs.python.org/2.7/library/cgi.html?highlight=cgi#cgi.parse_header)
to correctly parse the Content-Type value but ignore parameters, JSON should
always be UTF-8 but I don't know about other supported Content-Type.
Fixes#21707
The issue is basically that the master has seen N minions-- and not all N are currently connected. The publish job returns to the salt-api that N minions got the job-- and it dutifilly waits for all the returns. With this we use the same ping timeout that the CLI does while waiting for returns. So once all minions are no longer running the job we will return.
Fixes#21707
The issue is basically that the master has seen N minions-- and not all N are currently connected. The publish job returns to the salt-api that N minions got the job-- and it dutifilly waits for all the returns. With this we use the same ping timeout that the CLI does while waiting for returns. So once all minions are no longer running the job we will return.
