Both approaches now use a pillar.auth.UserClass instance. g.current_user
is now always set to that instance, even for web entry points.
This UserClass instance can still be keyed like the old dict, but this is
for temporary compatibility and shouldn't be relied on in new or touched
code.
This removes the ability of updating service accounts through the CLI
(something we never used anyway), now that service accounts cannot be
uniquely identified by their email address.
A PUT request on /api/user/{user-id} by the user themselves would allow
too much, and would allow self-granting of roles (including admin),
group membership (so join any arbitrary project) and pretend to be
service accounts.
- Moved pillar.api.utils.{gcs,storage} to pillar.api.file_storage_backends
- Implemented GCS and local storage using abstract Bucket and Blob classes
- Removed file processing from the Blob class, and kept it in the
file_storage/__init__.py class. That way storage and processing are
kept separate.
These changes mostly revolve around the change in ObjectId constructor
when running on Python 3.6. Where on 2.7 the constructor would accept
12- and 24-byte strings, now only 12-byte bytes and 24-character strings
are accepted. Good thing, but required some changes in our code.
Other changes include hashing of strings, which isn't supported, so they
are converted to bytes first, and sometimes converted back afterwards.
The 'manual fixups' are:
- incorrect use of dict.items() where dict.iteritems() was meant; this
results in list(dict.items()), which I changed to dict.items().
- removal of 'from __future__ import' lines, which 2to3 changes into
empty lines; I removed the empty lines.
Refactor of pillar-server and pillar-web into a single python package. This
simplifies the overall architecture of pillar applications.
Special thanks @sybren and @venomgfx
