Open ghost opened 5 years ago
I also see this error in production. Here is the code branch that triggers the IntegrityError (in v1.2).
I don't know if this is triggered by a race condition (the atomic decorator on the method would not prevent this) or if this is a logic bug in save_bearer_token
.
When this triggers in save_bearer_token
the state of variables is as follows:
refresh_token_code
is a string valuerefresh_token_instance
is according to my log a <RefreshToken: redacted>
(so isinstance(refresh_token_instance, RefreshToken)
should be True
previous_access_token
must be falsy to trigger the creation, so apparently wasn't found during the previous query So it looks like a race condition happens at this line between reading previous_access_token
and creating a new access token.
So maybe this block should be wrapped in an inner transaction with IntegrityError
handling?
try:
with transaction.atomic():
access_token = self._create_access_token(
expires,
request,
token,
source_refresh_token=refresh_token_instance,
)
refresh_token = RefreshToken(
user=request.user,
token=refresh_token_code,
application=request.client,
access_token=access_token
)
refresh_token.save()
except IntegrityError:
# Try getting the apparenly already created new access_token from the database
Hi, i'm new in django and i don't know exactly what is going on with this block code . but i have this error in my production too(small project for school) . my question is: 1-is this error dangerous? 2-what happen to my client when this error happen?(they can't login again or ...) i can't anywhere to ask my question unless here and if this place isn't appropriate please forgive me.thank you
I was just debugging this myself. #649 is indeed the fix that landed in master
that passes my parallel request test:
$ parallel -N0 http POST http://localhost:8000/o/token/ grant_type=refresh_token client_id=development refresh_token=vpkGCDH80hEU5usZek0seQFNApkPr5 --ignore-stdin --form ::: {1..5}
If the maintainers could release to PyPI that would be awesome!
Is it possibly solved by https://github.com/jazzband/django-oauth-toolkit/pull/810? It is part of 1.3.1 release
Stack trace:
Packages: