Currently testing in SOD: API calls must now use the tenants correct public endpoint
We're currently working on forcing apps to use the correct public endpoint for the API calls. This was implemented in SOD yesterday, and if you are now experiencing 401 response when trying to perform an authenticated API call then make sure you are actually hitting the correct endpoint for this tenant.
For example: If you have hard coded sod.superoffice.com/custxxx/api/v1/ and the web_api url returned in the ID Token is sod2.superoffice.com/custxxx/api/v1/ you will likely see the HTTPS status code 307 redirect and have connectivity issues.
The netserver_url and webapi_url claims are returned in the ID Token:
https://docs.superoffice.com/authentication/online/index.html#id-token
https://docs.superoffice.com/authentication/online/validate-security-tokens.html#superoffice-specific-claims
The endpoint is also returned in the tenants status: https://docs.superoffice.com/apps/tenant-status/status-page.html
Alle Antworten (7)
Hi,
On what interval could this change for a customer? For example if we authenticate using a system user for a long running process, where the system ticket is valid for 6 hours. Could it be that within those 6 hours the endpoint could change?
Do note - we identified a problem and have disabled the rule in SOD for now. It will be turned on again early next week, we will let you know here when it is active again.
HTTPS status code will also change to 421: 
Here is more information about what's actually happening, and what this means for your online integrations.
First I would like to make it clear that this only impacts tenant web service URLs. The following services are fixed, and not affected by this change.
- OAuth and OpenID Connect
- PartnerSystemUser
- Tenant status endpoint
Today, the web service URLs use one environmental subdomain, i.e.:
development: https://sod.superoffice.com
stage: https://qaonline.superoffice.com
production: https://online.superoffice.com
We introduced support for more than one subdomain awhile ago, but are now going to begin enforcing use of it for tenant resources. This means applications accessing supported protocols (SOAP/REST) can expect different tenants to have different resource URIs. For example, any one application can communicate with three different tenants on three unique subdomains.
https://sod.superoffice.com/cust12345/api/v1
https://sod2.superoffice.com/cust12346/api/v1
https://sod3.superoffice.com/cust12347/api/v1
Ideally these URLs should remain sticky, but due to load balancing issues, the subdomain for any given client might change at any given time, and clients must handle this gracefully.
For several years now, we have recommended integrations periodically use the Tenant Status Page to get and verify a tenants API URI. We have also include the practise in our WebApi examples before every API invocation.
We are in the process of assessing and updating all nuget packages that are impacted by this.
So far we have identified an issue with AspNet.Security.OAuth.SuperOffice.
The AspNet OAuth provider would fail because it tried to obtaining profile information from the https//{environment}.superoffice.com/{tenant}/api/v1/user/principal endpoint. This has been updated to support more flexible subdomains, and the maintainers have accepted a pull-request to fix this issue. A new package should be published soon. Publishing is at the discretion of the maintainers and not under our control. It is open source, so anyone can fork the repo and adopt it at anytime.
The SuperOffice.WebApi should not be affected in anyway. There is a helper static SubDomain class that is used by the Authorization libraries, and as stated above authentication/authorization endpoints are fixed and not affected by this new behavior.
Hope this helps!
Hi Tony,
Could you clarify what the issue is with these two packages?
As far as I understand, SuperOffice.SystemUser.Client only uses fixed URLs, namely the OpenID Connect configuration endpoint and the PartnerSystemUser service. What problems would we face if we don't upgrade this package?
We already use AspNet.Security.OAuth.SuperOffice in production, where some tenants have the online2.superoffice.com or online3.superoffice.com and according to our logs the /currentPrincipal endpoint works on any subdomain. Will this change in the future?
What is our deadline to upgrade these packages?
Thank you for your help.
This is now live in SOD, with a message on the login page. See this post also: https://community.superoffice.com/no/technical/forums/general-forums/announcements/breaking-changes-api-urls-for-online-tenants/