source refresh token is always null

[singhravi1]

Every access token is created with the source_refresh_token as null.

If we have specified this field as one to one, it should be stored in the access token object.

[n2ygk]

Access tokens only have a source_refresh_token if they've been obtained via a Refresh Token -- which is optional for Authorization Code flow and not even permitted for Implicit flow. So it is "normal" for the source_refresh_token to be null in many cases.

…

On Wed, Dec 12, 2018 at 10:02 AM singhravi1 ***@***.***> wrote: Every access token is created with the source_refresh_token as null. If we have specified this field as one to one, it should be stored in the access token object. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#674>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJ5d8Iot5j8M4FD49dnyM0sXfwksdUmks5u4Rp-gaJpZM4ZPnVX> .

[singhravi1]

@n2ygk
Yep, i just noticed this. Thanks.

Few problems caused by this when using with SQL server (I'm bound to use this database 😢 ):

• as it is one to one field, its causing unique constraint failed (can we change one to one to Foreignkey field in refresh token model as well as access token model?)
• I had to remove migrations folder in oauth2_provider as it causes cannot update type of an AutoField error. And ran makemigrations command separately for oauth2_provider.

[n2ygk]

See #668 here and michiya/django-pyodbc-azure#189 which fixes this. You are not the only one stuck using SQL Server;-)

[singhravi1]

Wow. This is interesting.

Both your PRs are on the point and needs to be merged asap.
But the issue causing unique constraint error will still be remaining?

Is the way i'm solving this correct?

[n2ygk]

The fix to django-pyodbc-azure is the correct fix. The relationship between access_token and source_refresh_token is OneToOne and nullable which is identical to making it ForeignKey unique and nullable. In order for this to work as-is with SQL Server, you have to either relax the uniqueness constraint (and take a risk;-) or fix the SQL DDL to work around SQL Server's failure to properly implement the NULL UNIQUE constraint. This workaround is implemented in michiya/django-pyodbc-azure#189 as further described here (pyodbc fix) or, alternatively, here (custom migration fix).

I strongly suggest the pydobc approach. Maybe upvote it and nag Michiya to merge;-) At least test and write a comment saying it works for you too.

[singhravi1]

@n2ygk
I installed your latest commit on forked django-pyodbc-azure.
It was able to migrate every migrations from oauth2_provider.
Actually it solved both the above issues. 🍾

Thanks

[n2ygk]

I saw a later note from you that this worked. Did you figure it out?

…

On Thu, Dec 13, 2018 at 1:15 AM Ravi Singh ***@***.***> wrote: @n2ygk <https://github.com/n2ygk> I installed your commit on django-pyodbc-azure. Then i installed django-oauth-toolkit and ran migrate command. But, as ususal, got stuck on migration 0005 with NotImplementedError: the backend doesn't support altering from/to AutoField. Am i doing anything wrong? Anything else i have to do? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#674 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJ5dwKqQ1IJ1j_VFDpkIIdYwq1ml4eaks5u4fCNgaJpZM4ZPnVX> .

[singhravi1]

Yes!

[n2ygk]

OK, closing this. Hopefully Michiya will merge it soon.