Closed MortenGuldbaek closed 6 years ago
Yes, same problem here. With v1.5, there is no longer a 2-parameter constructor for AadHttpClient that allows you to pass the resource ID for the AzureAD-protected resource. Code that worked in v1.41 does not compile in v1.5. When I use the parameter-less constructor for AadHttpClient in v1.5, I cannot properly initialize the AAD client HTTP object with the target resource ID. I know things will never work unless I can find some way to pass the Azure resource ID to create the AAD access token correctly.
I cannot tell if this is a bug with the AadHttpClient class in v1.5 or if there is some new programming technique I am supposed to use that is not yet documented. How do I pass the resource ID with this new model?
We are working on fixing this with updated npm packages within upcoming days. Sorry for the inconvenience.
I assume that you will be adding the AadHttpClientFactory class into the API to fix this issue. I see in the docs that AadHttpClientFactory offers there two methods.
getStandardClient(resourceEndpoint: string): AadHttpClient; getExtendedClient(resourceEndpoint: string): AadHttpClient;
Here is a minor recommendation you can take or leave. The parameter name of resourceEndpoint is ambiguous because it could refer to either the base URL or the resource ID. I think it would be better to change the parameter name to resourceId or aadResourceId. With many APIs, these two values are the same. But with some APIs such as the Power BI Service API, they are different.
API Root URL: https://api.powerbi.com Resource ID: https://analysis.windows.net/powerbi/api
Naming the parameter resourceId to me removes the ambiguity.
One other comment about the current v1.5 build. You have marked the two-parameter constructor for AadHttpClient as an internal member so we cannot use it to create instances. However, it is still possible to create a new AadHttpClient object using the default, parameter-less constructor of the AadHttpClient class. I would assume that you would want to mark the default, parameter-less constructor of the AadHttpClient class as an internal member as well to remove all AadHttpClient class constructors to force the creation of an AadHttpClient instance through the AadHttpClientFactory class.
Temporary solution here: #2093
Fix for this will be out in the SharePoint Framework v1.5.1, which will be released soon.
This should be now addressed with the 1.5.1 release, so would request to validate the situation with following. Here are short release notes for 1.5.1 release - https://github.com/SharePoint/sp-dev-docs/wiki/Release-Notes-for-SPFx-Package-Version-1.5.1.
We haven't been able to test this out in the 1.5.1 release, but can confirm that it works using the AadHttpClientFactory flow provided in version 1.6.0, which solves our issues.
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues
Category
Expected or Desired Behavior
Observed Behavior
Trying to instantiate AadHttpClient in 1.5 plus-beta throws the following error: The value for "serviceScope" cannot be undefined (roughly translated from Danish).
Mind you that this is is working in 1.4.1 (with supplied with AadHttpClient constructor arguments).
Reading the documentation for AadHttpClient references the AadHttpClientFactory class, but this is nowhere to be found in the plus-beta packages.
Steps to Reproduce
Can you please advice on how we should use AadHttpClient in version 1.5.0-plusbeta, as no tutorials seem to be mentioning a new approach, and I cannot find the package.
Kind regards from Morten