Changelogs » Adarnauth-esi

PyUp Safety actively tracks 262,873 Python packages for vulnerabilities and notifies you when to upgrade.

Adarnauth-esi

1.14.4

This release prevents any token refresh logic from being run if new=True is passed to the decorator.

1.14.1

Certain operations rely on GET requests with url parameters which are not appended to the URL until after the key is generated, resulting in key collisions. Key generation is now the hash of method, url, params, and payload.
  
  allianceauth/allianceauth877
  
  An additional convenience method is also included: [`esi.clients.minimize_spec`](https://github.com/Adarnof/adarnauth-esi/blob/v1.14.1/esi/clients.pyL218), which accepts a swagger spec dict, list of resources, and list of operations to keep. This removes all defninitions from the spec dict which are not tagged as a desired resource and are not a desired operation name. This is useful to reduce bloat when shipping a swagger spec with your app.

1.4.13

I haven't updated the scope list since the initial release - there are plenty out there that don't get automatically creasted in migrations. If a scopes was unrecognized (such as the first time seeing one of these new scopes) then it would be excluded from the list of scopes used to filter tokens. This is obviously incorrect behaviour - if we don't have the scope on file how can we have tokens with it? This update corrects this behaviour and fixes an issue with filtering for no scopes.

1.4.12

Turns out the length of access tokens and refresh tokens isn't static: it depends on a whole bunch of things, one of which is number of scopes. Now that it's possible to request up to 60 scopes per token, people are receiving refresh tokens longer than 254 characters which gets truncated when saved. This alters the character field to a text field which has no length limits.

1.4.11

https://code.djangoproject.com/ticket/18378
  
  This update changes how `require_scopes_exact` handles filtering: it explicitly selects `pk` and `scopes__id` so that the `scope_id` column ends up in the select statement, which avoids an SQL bug where it doesn't recognize the column in the having clause when used in a `Q` filter.

1.4.10

When a field is passed a list of models, it coerces them into database values by collecting their primary keys. In v1.4.8 I changed the scope query to search by scope name, so when looking for integers it found no scopes. This lead to the deduplication method incorrectly identifying the first token with the same number of scopes for a given character as equivalent as it did not have the actual scope models to filter by, replacing it with the newly created token.

1.4.9

v1.4.8 broke filtering by scopes if passed a queryset with length 1. This fixes it.

1.4.7

When the SSO servers are having a bad time and send back bad responses, they don't always come with an error message. The oautlib package then thinks the response is OK so it checks for the access token. Upon not finding said token it raises a `MissingTokenError` which until now had been interpreted as a reason for token invalidation.
  
  Because it seems this happens fairly often and is leading to token hellpurging this is instead re-raised as a `IncompleteResponseError`.
  
  Tokens which fail to refresh when a `.require_valid()` is used will be excluded from the returned queryset.

1.4.6

Part of the swagger API specification is the ability to define data structures ('models') for API responses. Recent updated to `bravado-core` (~4.13) and the swagger spec published by CCP have resulted in parsing of spec models and two distinct errors:
  - duplicate model names are defined in the spec provided by CCP which raises an error on swagger spec parsing
  - returned models are not pickle-able which breaks response caching
  
  This release adds an extra kwarg to spec generation which prevents returning data as models, favouring dictionaries.

1.4.5

A part of the OAuth spec as yet unimplemented by CCP until recently is the ability, upon refresh of an OAuth token, to return both a new access token and a new refresh token. This refresh token was being ignored leading to issues with subsequent refreshes (instead resulting in a `InvalidRefreshToken` error).
  
  This release records both the access and refresh tokens when refreshing.

1.4.3

Removes installation barrier for use with Django 2.0. Allegedly it works.

1.4.2

Experimental support for Django 2.0a1 by defining `on_delete` for foreignkeys and changing `reverse` imports to its new location. Drops support for Django<1.10.
  
  Additionally allows initialization without `ESI_SSO_CLIENT_ID`, `ESI_SSO_CLIENT_SECRET`, and `ESI_SSO_CALLBACL_URL` settings if `settings.DEBUG` is `True`. This is useful for testing.

1.4

This release adds support for initializing a client from a spec file shipped with your project by passing its path as the `spec_file` kwarg. The "old" way of specifying resource versions is depreciated.
  
  Additionally this release adds caching of get requests according to the `Expires` HTTP header. This can be disabled by setting the `ESI_CACHE_RESPONSE` setting to `False`.

1.3

This release changes how SSO returns are handled.
  
  Previously every return would result in a new token. However on the EVE site, under the Third Party Applications sections, additional entries are not consistently created when tokens are returned with duplicate scopes (as in, if there was already a token granted to the application with the same scopes, another SSO request would not result in a new entry BUT it would result in a new token in the database).
  
  Now tokens returned to us with scopes we already have (matching exactly, not inclusively) will not result in a new token in the database, but will be used to update existing database entries and the existing one will be returned to the view. This better matches the end-user experience. To emulate the old one-token-per-callback behaviour set `ESI_ALWAYS_CREATE_TOKEN` to `True`.
  
  Also per 1 you can pass the code to the manager instead of the request so it can work in an API environment more easily.

1.2.2

This prevents Spec construction without an initialized RequestsClient, which would occur using the factory without a token or datasource provided.

1.2.1

Properly catches OAuth-related errors and ignores connection errors. Tokens will not be deleted if the connection to the server is bad.

1.2

Clients can now be initialized with mixed resource versions. Specify the desired version as a kwarg of the form `Universe='v1'` through tokens or the factory.

1.1.1

Token.get_esi_client` now accepts the `version` kwarg and passes it to the factory.

1.1

In keeping with [CCP's recommended practices](https://developers.eveonline.com/blog/article/breaking-changes-and-you), this allows initialization of swagger clients for specific API versions. Simply pass the `version` kwarg to the client factory. Note that not all resources will be available on versioned clients: only resources with an available version matching the one specified will be available on the returned client. Multiple clients will be needed to access resources of different versions.

1.0.1

Security concerns were raised with having both the access token and refresh token visible on the admin site. These fields have been hidden from the admin site.

1.0

First fully-functional release of the package.