IUserRequestOptions.authentication should be an ArcGISIdentityManager

[tomwayson]

Describe the bug

In 3.x IUserRequestOptions.authentication was a UserSession, so in 4.x I would expect IUserRequestOptions.authentication to be an ArcGISIdentityManager, but it is the more generic IAuthenticationManager.

I'm currently migrating from 3.x, and all of my code that uses IUserRequestOptions is broken b/c it expects authentication to have properties that were on UserSession (token, etc).

I don't believe that it was our intent to make IUserRequestOptions more generic, b/c it now has the exact same signature as IAuthenticatedRequestOptions, so this looks like a bug to me.

Reproduction

n/a

Logs

System Info

4.3.0

Additional Information

No response

[tomwayson]

I see that authentication was changed to IAuthenticationManager in #1186.

I was able to get past my problem for now by going back to v4.2.3 (and the corresponding portal and feature-service packages).

Not sure whether that makes this a bug or not. Feels like it should be since my code works on 4.2.3 but would break if I upgrade to 4.3.0.

[patrickarlt]

@tomwayson with the release of the new API key implementation last year API Keys can now perform any portal operations that they are scoped for so IUserRequestOptions.authentication should work for anything that that the getToken() and getUser() methods defined by IAuthenticationManager

I think your running into this because you are upgrading from 3.x. In 4.x you should generally rely on the .getToken() method rather then the token getter if you need the token. We don't really use .token in the code anywhere. https://github.com/search?q=repo%3AEsri%2Farcgis-rest-js%20.token&type=code

I do agree there are 2 things that are weird:

1. IUserRequestOptions and IAuthenticatedRequestOptions are the same now which I missed in feat: make API keys work with all portal methods #1186.
2. Having IAuthenticationManager (the interface that defines a manager) and AuthenticationManagerBase (our shared implementation subclass) is a little confusing.

Is your code actually broken or is it just failing to compile and throwing type errors?

[tomwayson]

Thanks @patrickarlt

Is your code actually broken or is it just failing to compile and throwing type errors?

So far just failing to compile and throwing type errors. I haven't gotten to the point where we're actually excercising the code in an app yet, but I think it should work.

Seems to me that rather than make IUserRequestOptions generic, we should have left that as is and instead updated the functions to expect an IAuthenticatedRequestOptions.

If you agree, I could take that on b/c it would be no more work than casting all of our instances of IUserRequestOptions.authentication to be an ArcGISIdentityManager.