Sepiida

Latest version: v18.96

Safety actively analyzes 682387 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 8 of 31

15.0

----
First I've removed support for setting up sentry via the log module. It's insufficient. You now *must* set up sentry integration
through the sentry module. This now requires that you provide a release version which will be provided to sentry. This is better
because it also will increase the context data sentry gets about our user accounts.

So, where you had

sepiida.log.setup_logging(sentry_dsn)

you should now do

sepiida.sentry.add_sentry_support(app, sentry_dsn, version)


The sentry module also includes a new function, handle_reverse_proxy, which can be used when operating behind an nginx proxy
to get the correct origin IP information to sentry. You should add a call to this function to the wsgihandle.py module in your
client application if you use nginx as a reverse proxy to something like uwsgi

Further, resource_name is now required whenever creating or updating permissions. This has ripple effects through the permission fixture in tests as
well as regular code that is just creating permissions. Any time you call permission.create or permission.update you should include a
resource_name. This value is only meaningful to the client application - sepiida expects no special meaning and permits any string value

Finally, when calling update_filters sepiida will now look at your current filters and start optimizing the request to pao based on those
filters. For example, if you are already filtering down to a single uuid, sepiida will now only request from pao whether or not you have access
on that specific resource. It also only requests the fields that it needs so it doesn't immediately throw away a bunch of data. This
should not effect anything about correctness or the API for update_filters, it should only effect performance, but it's a big change so worth mentioning

14.3

----
Fix support for ?fields=[...] requests when doing a GET on a collection of resources. Previously we supported this on a GET
on an individual resource but we didn't have any tests around a GET on a collection and I found out recently that this support was
broken when I wanted to use it and I couldn't. So now it's fixed. Let's say you had a resource foo with a property bar. You can ask for
a list of foo resources and include *only* the property bar with

GET /foo/?fields=[resources.bar]

The reason you include 'resources' in that request is because the collection embeds matching resources in the 'resources' property. This
makes it possible to ask for just metadata on a resource collection

14.2

----
Add a new hook, add_origin_handler() which injects the origin of the request into the uwsgi context so it can be logged

14.1

----
Add a unique request ID to every request. You have to opt-in to this via the add_request_id_handler() function in sepiida.session. This request ID will then get passed on to
downstream services if you use sepiida.request.user_session()

14.0

----
The major breaking change in this release is that now we require a value for the origin when setting up permissions. So the
signature has changed from

permissions.configure(pao_root)

to

permissions.configure(origin, pao_root)

The origin value should be something like https://models.authentise.com

13.4

----
Add fields.Anything type. This is a field that can literally be anything, it does no packaging and no validation

Page 8 of 31

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.