For normal EDL auth, we aren't currently getting the JSON payload.
When a user attempts to log in to an EDL App and reject/avoids accepting the EULA, TEA does not receive the code value necessary to proceed through the rest of the process. Instead of the user being 302 redirected to https://<redirect_uri>?code=<code>, the user is sent to https://<redirect_uri>?error=access_denied .
In that case that originating https://uat.urs.earthdata.nasa.gov/oauth/authorize request has the app_type=401 parameter, 302 redirect is a little more complex: https://<redirect_uri>?error=access_denied&error_msg=App%20EULA%20has%20been%20updated,%20please%20reauthorize%20the%20application%20via%20the%20Earthdata%20Login%20GUI
However, at no point in the process is there a JSON payload, nor is there a resolution_url value.
This behavior is correct (because its new!) in shared token handling:
https://github.com/asfadmin/thin-egress-app/blob/devel/lambda/app.py#L536-L544
For normal EDL auth, we aren't currently getting the JSON payload.
When a user attempts to log in to an EDL App and reject/avoids accepting the EULA, TEA does not receive the code value necessary to proceed through the rest of the process. Instead of the user being 302 redirected to
https://<redirect_uri>?code=<code>
, the user is sent tohttps://<redirect_uri>?error=access_denied
. In that case that originatinghttps://uat.urs.earthdata.nasa.gov/oauth/authorize
request has theapp_type=401
parameter, 302 redirect is a little more complex:https://<redirect_uri>?error=access_denied&error_msg=App%20EULA%20has%20been%20updated,%20please%20reauthorize%20the%20application%20via%20the%20Earthdata%20Login%20GUI
However, at no point in the process is there a JSON payload, nor is there a resolution_url value.
I'd propose that instead of:
the 302 is to:
... then, downstream apps (like TEA) can reformat that response to a JSON payload.
In terms of TEA though, this is not a tractionable ticket until EDL behavior is changed.