You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve Oauth2 API for handling tokens persistence with SQL #207
I'm trying to accommodate storing my tokens in an SQL database, and trying to extend the OAuth2 class to enable storing and retrieving the tokens from the database. The _refresh_lock is something that is naturally also managed by the same database. (You have a conceptually similar implementation for redis with RedisManagedOAuth2)
What you would typically do with SQL in order to lock a specific row to update it (exactly what we want to do here) is use the SELECT ... FOR UPDATE command, which locks and retrieves the data at the same time
defrefresh():
withself.refresh_lock:
tokens=self.get_tokens()
# ... proceed with logic to update them
What I'm looking for is this
defrefresh():
withself.select_for_update(...) astokens:
# ... proceed with logic
Well, I can't really extend the class to achieve that unless I rewrite the whole methods refresh and revoke. I think a better API to express the need to "lock tokens and retrieve them" is with its own context manager function, that can have a default implementation that can be overridden. This contextmanager can be trivially rewritten to use select for update
defrefresh():
withself.lock_tokens(...) astokens:
# ... proceed with logic@contextmanagerdeflock_tokens():
withself.refresh_lock:
yieldself.get_tokens()
I think you can accomplish this with the current API, by creating a custom lock-like object that calls your SELECT .. FOR UPDATE and saves the tokens as state on the object. Entering the context manager via with self._refresh_lock: will issue your SQL command and make the tokens available until __exit__ is called. You could then override _get_tokens to simply return the stored tokens.
Yes that's right. I'm merely suggesting what I think is an improvement that looks like the right abstraction to me and can avoid a hidden state solution.
Activity
Jeff-Meadows commentedon Jun 12, 2017
I think you can accomplish this with the current API, by creating a custom lock-like object that calls your
SELECT .. FOR UPDATEand saves the tokens as state on the object. Entering the context manager viawith self._refresh_lock:will issue your SQL command and make the tokens available until__exit__is called. You could then override_get_tokensto simply return the stored tokens.dtheodor commentedon Jun 12, 2017
Yes that's right. I'm merely suggesting what I think is an improvement that looks like the right abstraction to me and can avoid a hidden state solution.