Failure to parse response from OAuth URL

[aaronkrusniak]

Hey again! Up until now, I've just been authenticating through arc.check_portal() / auth_binding() — worked great for testing, but trying to move to auth_client() using OAuth so we can use this new package in our automated scripts and stuff. (Sometimes Arc Pro automatically logs you out of your portal after a period of inactivity, so unfortunately I don't think auth_binding() would work non-interactively in the long term for us.)

Unfortunately, running into a problem with auth_client() where I'm getting the following error:

Error in `httr2::oauth_flow_client_credentials()`:
! Failed to parse response from
  `client$token_url` OAuth url.
Caused by error in `resp_body_json()`:
! Unexpected content type "text/plain".
• Expecting type "application/json" or suffix
  "json".
Run `rlang::last_trace()` to see where the error occurred.

I thought it was probably something to do with the way our internal enterprise is set up, but I double checked with our administrator and we think we have the OAuth client ID all set up properly. (And I have the ID set to my environment variables correctly, and have restarted R, etc.)

What stumped me is when I tried auth_code()— I'm able to log into our enterprise portal and receive an OAuth code just fine. However, when I copy that code into R, I get the exact same error as above. The code looks to be a 216-character long token that always ends in ..; I tried putting it in raw as well as in quotes and got the same result either way.

Not sure how exactly to give you a reprex for this one, given we're on an enterprise portal and it's probably not a good idea to paste the raw tokens here. But let me know if there's anything I can give you that would make this any easier to look into; I'm happy to help any way I can!

[JosiahParry]

Yeah, lol definitely not a good idea! Thank you for bringing this up. I have seen this before when working with some custom geocoding services.

This error message tells me that the body is sent as plain text instead of the json that it was expecting. Since this is an issue with {arcgisutils} I'm going to migrate it on over.

Do you know what version of ArcGIS Enterprise you're running on? That might help me.

[JosiahParry]

This comes from {httr2}

httr2:::oauth_client_get_token
function (client, grant_type, ..., error_call = caller_env()) 
{
    req <- request(client$token_url)
    req <- req_body_form(req, grant_type = grant_type, ...)
    req <- oauth_client_req_auth(req, client)
    req <- req_headers(req, Accept = "application/json")
    resp <- oauth_flow_fetch(req, "client$token_url", error_call = error_call)
    exec(oauth_token, !!!resp)
}

What this is telling me is that the response from your Enterprise is not returning application/json as it should be, instead the content-type is text/plain. My guess, though, is that it is actually json in the response with the content type incorrectly set.

[JosiahParry]

One thing to also ask your admin is if there is a reverse proxy or something which is modifying the headers.

Edit: in the mean-time, could you explore using an API key and using that with auth_key() ?

[aaronkrusniak]

Yeah, that would make sense to me. Wonder if maybe there's a way to check for plain text responses and coerce them to JSON, if possible, from the package side? Or if there's a way to verbose-ly get whatever that plain text response is, that might be helpful to look at too, for debugging purposes.

Our admin says we're on Enterprise 10.8 here! I can ask about the reverse proxy and see if he knows anything on that front.

Not sure about the API key— the documentation here talks about them vis-a-vis the ArcGIS Platform or Places Service; do you know if there's a way to set up an API key in an enterprise portal? We'd probably need to stick with the geocoder we have in there, for our purposes— but I'm on the data science side, not the IT admin side, so maybe there's a different way of setting this up that I just don't know about :)

[JosiahParry]

There isn't any way for us to change the oauth client flow to accept plain text input. That would have to be reported in {httr2} or we would have to write the OAuth flow from scatch which feels a bit out of scope. Above all, I believe that accepting text/plain I think would be a security risk.

I'm not sure what the best way to address this is because the Enterprise server should be returning application/json in the Content-Type header and not text/plain.

[aaronkrusniak]

Oh!— you're so right, of course {httr2} is handling all that, not sure why that didn't click for me earlier. Yup, totally out of scope for this, then. And the security concern is also valid, I hadn't thought of that either.

FWIW, just heard back from our GIS admin— he attests that the enterprise is returning JSON, and that we have no reverse proxies going on.

[JosiahParry]

FWIW, just heard back from our GIS admin— he attests that the enterprise is returning JSON, and that we have no reverse proxies going on.

I am quite sure that the content itself is json. However, the request that it is sending has a header set incorrectly.

For example, look at this response header from a random website (you can inspect this by opening your browser's developer tools and going to network and clicking one of the requests)

Responses typically have this Content-Type header which specifies what kind of content is being returned. Perhaps they can check the devtools and confirm that the content type is application/json

[aaronkrusniak]

Sure, I'll pass that info along— thanks, Josiah!

[JosiahParry]

@aaronkrusniak wonderful! Let me know what you find. If it is text/plain perhaps we can make a support ticket and determine if this is a bug or a configuration issue. If that happens, please include jparry at esri dot com too :)