When applying a site-level provisioning template, the HubSiteUrl property always fails with a warning, which is possibly due to a bugged implementation.
Before attempting to make the association, the framework does the following check (TenantExtensions.IsCurrentUserTenantAdmin --> IsCurrentUserTenantAdminViaSPO):
var adminSiteUrl = clientContext.Web.GetTenantAdministrationUrl();
try
{
// Connect to the Admin Site
using (var adminContext = clientContext.Clone(adminSiteUrl))
{
// Do something with the Tenant Admin Context
Tenant tenant = new Tenant(adminContext);
tenant.EnsureProperty(t => t.RootSiteUrl);
// If we've got access to the tenant admin context,
// it means that the currently connecte user is an admin
return (true);
}
}
catch
{
// In case of any connection exception, the user is not an admin
return (false);
}
This never succeeds and fails 401, falling into the catch block. To me it makes sense that it would fail, because the authentication is against a SharePoint site. Attempting to use that same token for the admin URL won't work because it is a different scope.
To resolve, this check would need to be replaced with one that obtains an admin token correctly.
The issue occurs for both application and delegated permissions.
When applying a site-level provisioning template, the
HubSiteUrlproperty always fails with a warning, which is possibly due to a bugged implementation.Before attempting to make the association, the framework does the following check (
TenantExtensions.IsCurrentUserTenantAdmin-->IsCurrentUserTenantAdminViaSPO):This never succeeds and fails 401, falling into the catch block. To me it makes sense that it would fail, because the authentication is against a SharePoint site. Attempting to use that same token for the admin URL won't work because it is a different scope.
To resolve, this check would need to be replaced with one that obtains an admin token correctly.
The issue occurs for both application and delegated permissions.
Originally discussed in #897