Handle filtering by unrecognized scopes

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.

Remove token length limits

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.

Avoid annotate and Q filter bug

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.

Correct handling of scope filtering

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.

Handle queryset scope filtering

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

Handle incomplete responses

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.

Prevent parsing and returning of spec-definied models

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.

Handle new refresh tokens

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.

Prevent token refresh when new=True required.

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

Django 2.0 Support

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