fix(enterprise): ensure a brand new token can be generated for servers federated with ArcGIS Enterprise

[jgravois]

this PR description has been edited heavily. previous drafts are available from the edited ▼ dropdown

proposed fix to enable the generation of tokens for ArcGIS Data Store content associated with ArcGIS Enterprise.

the tweak i'm proposing generalizes the comparison of the two relevant urls and gives a ✅ as long as the portal and service url share the same sub.domain.com. introspects the current session to see whether a token is already available. if not, and both username/password are present (indicating that the session was not instantiated for an OAuth flow), then a request to fetch one manually is fired.

STR:

// real portal instance, fake username and password
const session = new UserSession({
  username: "c@sey",
  password: "jones",
  portal: "https://portalhostds.ags.esri.com/gis/sharing/rest"
});

session.getToken("https://serverhostds.ags.esri.com/gis/rest/services/Hosted/restjs/FeatureServer")
  .then(token => {
    console.log(token);
  })

AFFECTS PACKAGES:
@esri/arcgis-rest-auth

ISSUES CLOSED: #161

paging @slibby in the hopes that he can provide a sanity check.

[jgravois]

substituting && is actually something that @noahmulfinger caught awhile back.

both of these tests need to be truthy. the , has the effect of disregarding the first match entirely.

[coveralls]

Coverage remained the same at 100.0% when pulling 2d4096a on bug/fix-portal-server-comparison into 2c52423 on master.

[patrickarlt]

@jgravois I think need to figure out a way to do this without assuming things like hosted data stores are always on the same domain as their portals. Depending on how users have deployed their store and portal this change might be totally meaningless.

Also isn't data store just a backend for a server that ends up getting federated with a portal anyway?

How does the JS API handle these calls?

[slibby]

1. is it even appropriate for us to assume that a service that shares the same base domain as an instance of ArcGIS Enterprise will use the same authentication scheme?
   No, we cannot assume this
2. if so, should the check be further weakened to compare only domain.com
   No, this is likely even more complicated
3. is there another, superior way to sniff out this type of relationship?
   Generally, we would use /rest/info on the AGS endpoint to identify the correct Token URL for that server. Similarly, you can use /portal/sharing/rest/portals/self/servers with a valid Portal token to identify valid federated servers as well.

[jgravois]

thanks for confirming @slibby!

thinking through this more deeply, the problem isn't actually a failure to associate the two resources. we should instead introspect the current session and fetch an entirely new token with the user's credentials (making sure to omit serverUrl) when one isn't already attached.

[patrickarlt]

@jgravois I still want to do a deeper review of this and test it out. I'm not sure the right approach is falling back to username and password. We still want to encourage users to us Oauth even on portals I think.

[jgravois]

We still want to encourage users to us Oauth even on portals I think.

i agree that we should promote OAuth as the preferred method of authentication and i'm happy to start working on some doc to explain why/how.

that said, devs can (and will) attempt to instantiate username/password UserSessions, both in node apps and for prototyping in the browser, so we need to make sure that works too.

[jgravois]

i'm still in favor of landing this fix, primarily because the pattern already works just fine for ArcGIS Online.

// fake username and password
const session = new UserSession({
  username: "c@sey",
  password: "jones"
});

session.getToken("https://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/")
  .then(token => {
    console.log(token); // HWYDXKHz4W-x979NNq6_E...
  })

[patrickarlt]

@jgravois Finally was able to take a look at this and these changes look good but there are a ton of merge conflicts to fix.

Other than that !

[jgravois]

thx @patrickarlt! i rebased and -f pushed to resolve the conflicts.