Fixed infinitely recursing GlobusApp login

[derek-globus]

• Fixed a bug where specifying dependent tokens in a new GlobusApp would cause the app
  to infinitely prompt for log in.

---

Why was this happening?

pr-1000 added support for dependent token evaluation by means of an AuthClient which leverages the attached GlobusApp and is used for polling user consents. With this addition, users could unintentionally get themselves into an infinitely recursing login loop with the following script.

import globus_sdk
from globus_sdk.experimental.globus_app import UserApp

NATIVE_CLIENT_ID = "61338d24-54d5-408f-a10d-66c06b59f6d2"
user_app = UserApp("my-simple-app", client_id=NATIVE_CLIENT_ID)

transfer = globus_sdk.TransferClient(app=user_app).add_app_data_access_scope("996383e6-0c85-4339-a5ea-c3cd855c2692")

user_app.get_authorizer(transfer.resource_server)

Assuming the app "my-simple-app" has no pre-existing tokens, the call to get_authorizer would raise a MissingTokenError. This error would be intercepted by the app and automatically drive a login flow to supply new tokens. Upon receiving an authorization code, the tokens would be passed through to ValidatingTokenAdapater.store_token_data_by_resource_server(...).

As a part of storing the token data, we validate that they meet both root scope requirements and dependent scope requirements. Evaluating dependent scope requirements involves that aforementioned AuthClient however polling Globus Auth for the user's current consents. This call (AuthClient.get_consents) would attempt to get an authorizer, which would in turn raise a MissingTokenError (the in flight tokens have yet to be stored as they're in the middle of validation). This error would be intercepted by the app and automatically drive a login flow to supply new tokens. And the loop continues indefinitely (goto previous paragraph).

---

To solves this problem, I removed dependent scope evaluation from token store. Dependent scopes are still evaluated on token retrieval. Root scopes are still evaluated on token storage.

---

📚 Documentation preview 📚: https://globus-sdk-python--1002.org.readthedocs.build/en/1002/

[sirosen]

It would be nice if we could somehow still do the validation work, but defer it until later in the process (when the consent client has already been instantiated).

I'm not seeing a quick-and-easy small change to do that, but I'd like to talk about maybe doing that at some point.

[derek-globus]

Well the consent client is instantiated, it just doesn't have tokens at the point that we need.

The path forward would probably be to have some complicated side-loading token business like:

  def _poll_for_consents(self, tokens_being_evaluated: TokenData | None = None):
     with self.consent_client.temporary_tokens(tokens_being_evaluated):
        resp = self.consent_client.get_consents()
        ...

but I don't know what a good version of that looks like (if one even exists).

[sirosen]

I was imagining a different path, where the consent client is only used to validate after the whole login + token loading business is complete. i.e. Imagine somewhere in the stack a consent_validation_mode=EAGER|DEFERRED flag which defaults to EAGER.

After the whole login flow is done, then the validation could run as a callback (mode=DEFERRED). But, as we're both saying, I don't see a good path to my vision here. At least, not right now.

[derek-globus]

Yep, very open to circling back on it in the future; maybe it's one of those things that once this is a little more battle tested the extension point becomes more obvious.