Closed ghost closed 1 year ago
This becomes a problem when there is a 2.x server that is upgraded to 3.x where the client tries to use the refresh token which occurs if the client didn't perform any API calls in the last hour.
Scenario: on 09:00 client connects to VPN 2.x server, all good. The client goes offline and comes back at 12:00, but the server has been upgraded to 3.x. As >1 hour has expired, the client uses to refresh token to get a new access token, but the token endpoint changed and now the client gets a 404, (or 401) response and shows an error box instead of triggering re-authorization.
We implemented a fix in the server that handles this situation when the server is upgraded from 2.x to 3.x:
https://git.sr.ht/~fkooman/vpn-user-portal/commit/4ee4d33dea34e09aacfcae5484cd9c76d6c29959
The app "caches" the OAuth token endpoint when storing an authorization. This is not great if the server changes endpoints, it will break and probably hit a wrong URL that now returns a 400, or 401, or whatever: everything except the proper OAuth error.
This makes the client show an error box which is bad. We want the client to reauthorize right away.
We worked around this in the case of
nl.eduvpn.org
by placing a fileoauth.php
in the location of the old endpoint that returns a 400 and some error message onhttps://nl.eduvpn.org/portal/oauth.php/token
:NOTE: this only works because during 2.x lifetime of nl.eduvpn.org the portal was on
/portal
and not on/vpn-user-portal
. For other servers this WILL NOT WORK.