ab5ea03025
There is a chance that offline storage could fall out of sync with the refresh token tables. One example is if dex crashes/is stopped in the middle of handling a login request. If the old refresh token associated with the offline session is deleted, and then the process stops, the offline session will still refer to the old token. Unfortunately, if this case occurs, there is no way to recover from it, since further logins will be halted due to dex being unable to clean up the old tokens till referenced in the offline session: the database is essentially corrupted. There doesn't seem to be a good reason to fail the auth request if the old refresh token is gone. This changes the logic in `handleAuthCode` to not fail the entire transaction if the old refresh token could not be deleted because it was not present. This has the effect of installing the new refresh token, and unpdating the offline storage, thereby fixing the issue, however it occured. |
||
|---|---|---|
| .. | ||
| internal | ||
| api_test.go | ||
| api.go | ||
| doc.go | ||
| handlers_test.go | ||
| handlers.go | ||
| oauth2_test.go | ||
| oauth2.go | ||
| rotation_test.go | ||
| rotation.go | ||
| server_test.go | ||
| server.go | ||
| templates_test.go | ||
| templates.go | ||