Possible server federation check bug

I’m attempting to run queryFeatures on a feature service in devext (ie https://servicesdev.arcgis.com/orgId/arcgis/rest/services/test/FeatureServer/0), but I ran into a possible federation issue.

UserSession.getTokenForServer checks the owningSystemUrl property, which in this case is https://devext.arcgis.com. However, my portal is set to https://devext.arcgis.com/sharing/rest, so the urls don’t match and a NOT_FEDERATED error is returned. I’m assuming the check on the owningSystemUrl should accept my portal in this case.

Relevant code (specifically line 703): https://github.com/Esri/arcgis-rest-js/blob/834ad79632f40c3d1abedf017d202a184bb25db3/packages/arcgis-rest-auth/src/UserSession.ts#L701-L709

cc @patrickarlt @jgravois

Note: This won’t be an issue for the servicesdev domain after https://github.com/Esri/arcgis-rest-js/pull/245 is released, since getToken will correctly recognize servicesdev as an arcgis.com server.

[noahmulfinger]

@jgravois You’re right, I looked at it again and the actual issue is that the owningSystemUrl was http://... whereas the portal was https://.... That’s what caused the regex failure.

[noahmulfinger]

@jgravois It will get resolved for servicedev.arcgis.com in the next release, but I wanted to point out more generally that when the portal is https://my.server.com/sharing/rest and the owningSystemUrl is https://my.server.arcgis.com, the NOT_FEDERATED error will be returned. That seems incorrect to me.