Technical Latest content Contact forms Forums Blogs Resources

Currently testing in SOD: API calls must now use the tenants correct public endpoint

lock
push_pin
done
Answered
6
7

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 

Margrethe Halvorsen Romnes
20 Oct 2022 | 03:40 PM

All Replies (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?

D
david@all-crm.nl
21 Oct 2022 | 10:27 AM
There is no interval for making these changes. If we need to, we may change it within these 6 hours.
If that happens there will most likely be because of an incident and a message will be posted on status.superoffice.com page.
Margrethe Halvorsen Romnes
21 Oct 2022 | 10:44 AM

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: 

Margrethe Halvorsen Romnes
21 Oct 2022 | 10:47 AM

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!

Tony Yates
24 Oct 2022 | 12:24 PM

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.

V
Veroniqueb@superoffice.com
25 Oct 2022 | 08:11 AM
Yes, SystemUsertClient will only use non-numbered subdomains.
Because AspNet.Security.OAuth.SuperOffice uses user/currrentPrincipal to obtain profile details, and this exists on the API subdomain (numbered), it is affected. That said, I did link to the PR that fixes this issue and a new package is expected to be published soon.
Tony Yates
25 Oct 2022 | 11:46 AM
"Yes, SystemUsertClient will only use non-numbered subdomains." So, what problems would we face if we don't upgrade the SuperOffice.SystemUser.Client package?
How is the AspNet.Security.OAuth.SuperOffice affected, if the /currentPrincipal endpoint works on all subdomains, as shown by my screenshot? Will this change in the future?
Once the new package with your PR is published, when do you expect us to release our apps with that new version?

V
Veroniqueb@superoffice.com
25 Oct 2022 | 12:40 PM
"Once the new package with your PR is published, when do you expect us to release our apps with that new version?"
There is not date set for publish to production yet, so what would you consider a reasonable amount of time?

Note that the end goal is to reduce load and improve user performance for our common customers.
Margrethe Halvorsen Romnes
26 Oct 2022 | 08:44 AM
We think one month should be enough to test all of our apps, fix bugs, if any, and release them.

V
Veroniqueb@superoffice.com
26 Oct 2022 | 11:44 AM
Hi Véronique,

I have revised my original reply, removing SuperOffice.SystemUser.Client from any affected list, as it should not be affected. That said, you can review the last commit to see that a subdomain validation is updated 'just in case'.
https://github.com/SuperOffice/SuperOffice.SystemUser.Client/commit/e3738259011c1023cbd7eedac10f32a78d2bd255

How is the AspNet.Security.OAuth.SuperOffice handler affected? Your assumption is that, because the user/currentPrincipal endpoint works today, it will continue to work once the redirects are in place, and that is just wrong. Perhaps I wasn't clear about that above? Technically, in its current state, the handler will use the subdomain you set as the "options.Environment" property. This only uses one of the non-numbered subdomain values. Therefore, the PR addresses this shortcoming by using the webapi_url from the id_token, with the correct [potentially numbered] subdomain to get the profile details from the user/currentprincipal endpoint. Make sense? If not, follow the link above to look and inspect the PR changes.

Hope this helps.

Tony Yates
31 Oct 2022 | 12:29 PM

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/

 

Margrethe Halvorsen Romnes
19 Apr 2023 | 06:10 AM
Is it correct that the change of removing netserver_url and webapi_url from the id_token claims is not live yet?

D
david@all-crm.nl
19 Apr 2023 | 07:11 AM
True, the change to remove these from the id_token is not yet live in SOD.
Margrethe Halvorsen Romnes
19 Apr 2023 | 07:46 AM

Add reply