#233 breaks the use case where a user is signed in and trying to access a public feature service

[tomwayson]

My app queries a public feature https://services.arcgis.com/bkrWlSKcjUDFDtgw/arcgis/rest/services/Hub%20Annotations/FeatureServer/0 and uses this as the portal: https://cityxcommunity.maps.arcgis.com/sharing/rest

It worked up until v1.4.1 (and I'd guess right up to #233).

Since upgrading to 1.5.0 I get 2 errors.

The first is that

That obscures the following NOT_FEDERATED error

Which is related to

[patrickarlt]

Since you aren't using the default portal it is likely failing this check https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-auth/src/UserSession.ts#L628-L629 then doing getTokenForServer() https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-auth/src/UserSession.ts#L678-L744 which will make a call to https://services.arcgis.com/bkrWlSKcjUDFDtgw/arcgis/rest/info?f=pjson to get authInfo.tokenServicesUrl which doesn't match your portal which means that this check is failing https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-auth/src/UserSession.ts#L701-L704.

So we have 2 options:

1. Trust org portals on ArcGIS Online like https://cityxcommunity.maps.arcgis.com/sharing/rest like we do the default ArcGIS Online portal https://www.arcgis.com/sharing/rest and fix https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-auth/src/UserSession.ts#L628-L629
2. Fix the check on https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-auth/src/UserSession.ts#L701-L704 to assume that if our portal is on an arcgis.com domain and our authInfo.tokenServicesUrl is on arcgis.com domain, then assume they are federated and continue trying to generate a token.

[patrickarlt]

@tomwayson also is there ANY reason to use https://cityxcommunity.maps.arcgis.com/sharing/rest over https://www.arcgis.com/sharing/rest? As far as I have been able to tell when using the REST APIs there isn't really a difference.

[tomwayson]

Thanks @patrickarlt, I did not mean to submit this issue yet, I was just using it to take notes as I was debugging and accidentally submitted it.

That said, I'm glad you weighed in!

I was basically going to propose your first solution above, but I wasn't sure of the ramifications.

is there ANY reason to use https://cityxcommunity.maps.arcgis.com/sharing/rest over https://www.arcgis.com/sharing/rest

The reason I'm using it is related to #239 - for Hub auth, we use the community org as the portal when we have the sign in/up. AFAIK - it's only technically needed in the case where they are signing up, b/c that ensures that the autoAccountCreateForSocial will create an org (not a public) account for them. However, b/c they are unauthenticated when we begin the OAuth flow, we don't know if they will be signing up for the first time, or logging in w/ an existing account, so we have to use community org as the portal.

As far as I have been able to tell when using the REST APIs there isn't really a difference.

One difference I notice is that if you use an org portal, the OAuth login page won't even let you log in if you're not a member of the org. If you use www for the portal, anyone can log in. I know WAB and our solution templates allow you to set the portal URL to an enterprise org. I'm guessing one reason might be to not even let users sign in if they are not in the org so they don't experience auth errors when trying to access items, layers, etc that are only shared w/ the org, but I don't really know.

Generally, I suspect that there are valid, non-Hub, reasons to use org portal urls.

[tomwayson]

Also, I was also wondering about a larger issue here, and that is that the service itself is public, and doesn't need any token for access. I know at the time of the request we have no way of knowing that, but I wonder if we should be trying to pre-emptively generate tokens at all until the request has failed w/ an auth error.

[patrickarlt]

@tomwayson of the 2 options I presented I liked option 1 more too. Do you want tackle this issue? If not I could probably get to it today since I'm not at UC.

As for the auth/un-authed requests thing I don't really have a good answer. Either we generate unnecessary tokens for public services or do what the JS API does and make a request, see if it fails, auth (2 more requests) and then try again with a token. Given that the retry approach costs another request I don't think we should do it.

It is however pretty easy to do yourself:

request(somethingThatMayOrMayNotRequireAToken).catch(e => {
  if(e.name === "ArcGISAuthError") {
    return e.retry(someSession)
  }
}).then(response => {
  // you can use the same handler for the success with or without a session.
});

[tomwayson]

Thanks @patrickarlt!

It'd be great if you wanted to take a crack at 1. I'm working on putting in place a workaround in my app (basically, don't use auth for that service b/c I know it's public) so we can demo it tomorrow. I'l be available to help review/merge/release if you are able to PR today.

[jgravois]

resolved by #245