as is, yielding sleep before registering the event listener as actually causing
saltnado to _miss_ the event entirely. instead of waiting before registering,
instead we just add the syndic_wait to the futures base timeout.
Without allow_unicode=True, unicode characters are processed through the
str representer and on Python 2 are dumped as a Unicode code point (i.e.
a literal \u0414). This commit makes allow_unicode=True the default in
our salt.utils.yamlloader.safe_dump() helper. It also adds a new
salt.utils.yamlloader.dump() helper which wraps yaml.dump() and also
makes allow_unicode=True the default.
To make importing and using our custom yaml loader/dumper easier, a
convenience module called salt.utils.yaml has been added, which does a
wildcard import from both salt.utils.yamldumper and
salt.utils.yamlloader.
Refs to yaml.load/dump and yaml.safe_load/safe_dump have been updated to
salt.utils.yaml, to ensure that unicode is handled properly.
This PR is part of what will be an ongoing effort to use explicit
unicode strings in Salt. Because Python 3 does not suport Python 2's raw
unicode string syntax (i.e. `ur'\d+'`), we must use
`salt.utils.locales.sdecode()` to ensure that the raw string is unicode.
However, because of how `salt/utils/__init__.py` has evolved into the
hulking monstrosity it is today, this means importing a large module in
places where it is not needed, which could negatively impact
performance. For this reason, this PR also breaks out some of the
functions from `salt/utils/__init__.py` into new/existing modules under
`salt/utils/`. The long term goal will be that the modules within this
directory do not depend on importing `salt.utils`.
A summary of the changes in this PR is as follows:
* Moves the following functions from `salt.utils` to new locations
(including a deprecation warning if invoked from `salt.utils`):
`to_bytes`, `to_str`, `to_unicode`, `str_to_num`, `is_quoted`,
`dequote`, `is_hex`, `is_bin_str`, `rand_string`,
`contains_whitespace`, `clean_kwargs`, `invalid_kwargs`, `which`,
`which_bin`, `path_join`, `shlex_split`, `rand_str`, `is_windows`,
`is_proxy`, `is_linux`, `is_darwin`, `is_sunos`, `is_smartos`,
`is_smartos_globalzone`, `is_smartos_zone`, `is_freebsd`, `is_netbsd`,
`is_openbsd`, `is_aix`
* Moves the functions already deprecated by @rallytime to the bottom of
`salt/utils/__init__.py` for better organization, so we can keep the
deprecated ones separate from the ones yet to be deprecated as we
continue to break up `salt.utils`
* Updates `salt/*.py` and all files under `salt/client/` to use explicit
unicode string literals.
* Gets rid of implicit imports of `salt.utils` (e.g. `from salt.utils
import foo` becomes `import salt.utils.foo as foo`).
* Renames the `test.rand_str` function to `test.random_hash` to more
accurately reflect what it does
* Modifies `salt.utils.stringutils.random()` (née `salt.utils.rand_string()`)
such that it returns a string matching the passed size. Previously
this function would get `size` bytes from `os.urandom()`,
base64-encode it, and return the result, which would in most cases not
be equal to the passed size.
* 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.
