obtaining system user tickets stopped working January 24th

lock
push_pin
done
Besvart
5

We wrote a customer specific python application using the RESTful API, following the System user flow. On January 24th, it suddenly stopped obtaining system user tickets, in spite of the client secret and certificate being valid until 2030. The app itself had been running for 165 days uninterrupted, but Superoffice may have been updated.

The problem is with the authentication endpoint https://online2.superoffice.com/Login/api/PartnerSystemUser/Authenticate

It suddenly started returning status code 200 with an HTML text string as response, when the app is expecting it to return JSON, instructed by "Accept" http headers.

This is double confusing, authentication should just succeed, but if it does not succeed, I would expect a 4XX status and/or a JSON error message.
Our app does not use sample libraries like https://github.com/SuperOffice/devnet-python-system-user but I can reproduce the error using that code.

5 t, 11 m siden | 06:00 p.m.

Alle Svar (5)

The auth endpoint is online environment (sod/stage/online) specific, not endpoint (online/online2/online3/online4) etc specific. So you should always use https://online.superoffice.com/Login/api/PartnerSystemUser/Authenticate

It's documented here

https://docs.superoffice.com/en/developer-portal/best-practices/tenant-status/check-status.html

We had the same error in our implementation of the auth flow of a system user, it indeed worked until the 24th, but there were changes last weekend that made that it now redirects to online.superoffice.com

5 t, 7 m siden | 06:04 p.m.
You just copied my URL in your response, but of course you mean: always use https://online.superoffice.com/Login/api/PartnerSystemUser/Authenticate

I did in fact try that too, but it returns 403, which perhaps is better, but not what I want.
So it looks like "online" is behaving differently from the way "online2" behaved prior to Jan 24th.
4 t, 48 m siden | 06:23 p.m.

The JSON payload for the 403 response is {"Token":null,"IsSuccessful":false,"ErrorMessage":null} which does not help much.

4 t, 41 m siden | 06:30 p.m.

Yes I meant online.superoffice.com 😀

 

We (and an external partner at a customer) had the exact same issue you described, which was immediately resolved when changing to online.superoffice.com. 

I would recommend contacting appdev@superoffice.com and specifying for which app & tenant you are getting this 403 error, they might be able to determine based op the app insights logging why you are getting this 403 response.

4 t, 40 m siden | 06:31 p.m.

Never mind, the 403 was caused by an error in my simulation code. The real production app just worked after the change.

Thanks David!

3 t, 55 m siden | 07:16 p.m.

Hi, 

We are having the same issue in customer apps that have been working for 1/2 years

Request an access token using REST API to: https://online2.superoffice.com/login/common/oauth/ticket OR https://online2.superoffice.com/Login/api/PartnerSystemUser/Authenticate 

 OK 200 response

 

 This is this response content – html SuperOffice login page, not JSON and not a user ticket. 

Have any API changes been documented somewhere?

Thanks,


Andy 

2 t, 4 m siden | 09:07 p.m.

All authentication calls needs to go via our main endpoint, so remove the number after https://online and use only

https://online.superoffice.com/Login/api/PartnerSystemUser/Authenticate

Or the endpoints from

https://online.superoffice.com/login/.well-known/openid-configuration

 

For API calls against your SuperOffice, then it's the correct endpoint which would be numbered as explained here: 

https://docs.superoffice.com/en/developer-portal/best-practices/tenant-status/check-status.html#endpoint

48 m siden | 10:23 p.m.

Legg til svar