Forum - REST API authentication issue

REST API authentication issue

Paul Timms

1-20-22

Operating system: Windows

A third party software company is attempting to authenticate to Standard ERP using OAuth2, but gets an error. They are set up in SERP, with REST API access, and they have the developer credentials, in which their redirect URL is specified. The error they're getting is:

{"type":https://tools.ietf.org/html/rfc7231#section-6.5.1,"title":"One or more validation errors occurred.","status":400,"traceId":"00-5b91718112e3b5458ed1b5930352eeae-ae47b096640e5546-00","errors":{"code":["Must not be null or empty"]}}

If I set up developer credentials with a different redirect URL, for example the web port of the SERP server, I can get an access token using SoapUI and their Standard ID. If I send this access token to them, they can use it and get the data. However, they need to be able to get the access token themselves. Does anyone know what the problem might be?

David Delač

1-27-22

Hello Paul,

Seems like there is an issue with the 3rd party tool you are using. Error that you provided us here is generated by that tool and not by us. OAuth2 is something we are still actively working on improving and there might be cases where it does not behave as expected. In order for us to be able to help you with this problem we need more information on what tool you are using and if possible a way for us to repeat. If there is no way to repeat then please provide with detailed description of what is wrong and what exact calls and steps you are doing to repeat it.

eg.: works when parameter-X is in body but doesn't work when parameter-X is in http header

Ideally you would create a bug report with a way to repeat this and we can have a look but good description might be sufficient.

Best Regards,
David D.

Paul Timms

2-9-22

Thanks David. The developers have come back with this point, do you agree with it? Is it Standard ERP which gives these tokens, or is it the Standard ID authentication server?

"I have also proven another issue with Standard ERP which has caused us significant problems and delays in development. Every two or three requests are rejected and we get an empty message returned from Standard ERP. If I put a break point between the request for the access token and the request that sends the data and let it wait 2 or 3 seconds it works every time. It seems to be a race condition on the API where it's not accepting the credentials fast enough. We will need this fixing before we are able to go live as this is stopping the required request from completing. I have unit test that can generate this problem, it seems to stop responding after 3 requests."

Paul Timms

2-9-22

They have added:

"Just to clarify, after further investigate, we get a 403 forbidden request every 2, 3 or 4 requests.

However with the break points in, and the three second wait, it seems to work every time."

Aldevinas Katkus

2-9-22

"Every two or three requests are rejected and we get an empty message returned from Standard ERP."

I have noticed this too, but not so frequently.

Paul Timms

2-11-22

Aldevinas, are you able to replicate this? It would be good to replicate on a sample data system on the latest release, so we can report it as a bug.

Aldevinas Katkus

2-14-22

Created byPaul Timms15:28 11 Feb 2022

Aldevinas, are you able to replicate this? It would be good to replicate on a sample data system on the latest release, so we can report it as a bug.

I have just upgraded our demo from 8.5 2021-11-24 (build 85420169) to 8.5 2022-02-02 (build 85420830) and cannot fetch any records anymore.
Never version client crashed when I tried to fetch records using Power BI, an older version did not crash.

hansa.log new version:
2022-02-14 17:00:56 (1) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2^M
2022-02-14 17:00:56 (1) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID^M
2022-02-14 17:00:56 (1) CallHal("OAuthCheckIfTokenIsValid")^M
2022-02-14 17:00:56 (1) CallHal("FindService")^M
2022-02-14 17:00:56 (1) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2^M
2022-02-14 17:00:56 (1) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID^M
2022-02-14 17:00:56 (1) CallHal("OAuthCheckIfTokenIsValid")^M
2022-02-14 17:00:56 (1) CallHal("FindService")^M
2022-02-14 17:00:56 (1) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2^M
2022-02-14 17:00:56 (1) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID^M
2022-02-14 17:00:56 (1) slot 4242819: clear^M
2022-02-14 17:00:56 (1) slot 4242819: allocated^M
2022-02-14 17:00:56 (1) slot 4242819: set usage to http^M
2022-02-14 17:00:56 (1) slot 4242819: set session to 4 from SetWebClArr^M
2022-02-14 17:00:56 (1) AD CallHal("EmailValidationStatusWithStdID")^M
2022-02-14 17:00:56 (1) AD Login ^M
2022-02-14 17:00:56 (1) AD Login Slot: 4242819 Session: -1^M
2022-02-14 17:00:57 (1) /THREAD(30) CallHal("OAuthCheckIfTokenIsValid")^M
2022-02-14 17:00:57 (1) /THREAD(30) CallHal("FindService")^M
2022-02-14 17:00:57 (1) /THREAD(30) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2^M
2022-02-14 17:00:57 (1) /THREAD(30) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID^M
2022-02-14 17:00:57 (1) /THREAD(32) CallHal("OAuthCheckIfTokenIsValid")^M
2022-02-14 17:00:57 (1) /THREAD(32) CallHal("FindService")^M
2022-02-14 17:00:57 (1) /THREAD(32) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2^M
2022-02-14 17:00:57 (1) /THREAD(32) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID^M
2022-02-14 17:00:57 (1) /THREAD(34) CallHal("OAuthCheckIfTokenIsValid")^M
2022-02-14 17:00:57 (1) /THREAD(34) CallHal("FindService")^M
2022-02-14 17:00:57 (1) /THREAD(34) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2^M
2022-02-14 17:00:57 (1) /THREAD(34) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID^M

old version:
2022-02-14 11:10:26 (1) CallHal("OAuthCheckIfTokenIsValid")

2022-02-14 11:10:26 (1) CallHal("FindService")
2022-02-14 11:10:26 (1) ENABLER: get functionality SERVICE_RESTAPI already resolved to 2

2022-02-14 11:10:26 (1) FindService(RESTAPI,) -> http(s)://18.156.208.209:443 for function DOOAUTHCHECKIFTOKENISVALID
2022-02-14 11:10:26 (1) M4USleep called on main thread: 100000
2022-02-14 11:10:26 (1) M4USleep called on main thread: 100000
2022-02-14 11:10:26 (1) TIMINGS: blocking slow web-call (2) to https://18.156.208.209:443/cloudcall took 0.2 seconds
2022-02-14 11:10:26 (1) backtrace called due to: slow webcall
2022-02-14 11:10:26 (1) -------------------- backtrace start -------------------------

...
[0x8d2f7e]
2022-02-14 11:10:26 (1) 19: /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f00b5d5e555]
..
[0x4129ee]

2022-02-14 11:10:26 (1) --------------------- backtrace end --------------------------
2022-02-14 11:10:26 (1)
2022-02-14 11:10:26 (1) dump of call stack
2022-02-14 11:10:26 (1) 00007F00B3C71311 + 35413 amainhal/HTSTools3.hal: OAUTHCHECKIFTOKENISVALID
2022-02-14 11:10:26 (1) slot 4242844: clear
2022-02-14 11:10:26 (1) slot 4242844: allocated
2022-02-14 11:10:26 (1) slot 4242844: set usage to http
2022-02-14 11:10:26 (1) slot 4242844: set session to 29 from SetWebClArr
2022-02-14 11:10:26 (1) AD CallHal("EmailValidationStatusWithStdID")

2022-02-

Paul Timms

2-15-22

I've updated my sample data test system to the current release. I've tried to get some data and the system doesn't crash, but gives a 403 error. In the server's hansa.log I see these two lines each time:

2022-02-15 14:55:49 GetShoppingBasket GetWebSessionUUID=EC880712-89A6E379-B7D32C00-91D70206-42FC9D07
2022-02-15 14:55:49 Web file not found: background.png

I already have an access token from the previous version but I've not been able to get a new one. With basic authentication I'm able to get data.

Paul Timms

2-15-22

I have now managed to get a new access token, but I'm still unable to get data using OAuth2, using the current release 2022-02-02. I get a 403 error each time.

Paul Timms

2-16-22

I've been doing some more testing with SoapUI, Postman and Google Developer Playground, in the latest release with sample data. Whilst each of these systems have been able to get an access token, both SoapUI and Google have usually failed with a 403 error when getting data. Postman was usually able to get data, even using the access token from either of the other two systems. Also, after Postman had got the data, it was then usually possible to get the data from the other two systems.

However, after restarting the SERP server, I have not been able to get data from any of the three systems, as they all return a 403 response.

I've been working with Simone on this and we're hoping to escalate this further.

Paul Timms

3-24-22

Update: The 403 error has been fixed and is in 2022-03-03 release candidate. Here are some more findings, using OAuth 2 for authentication.

Postman, Google Developer and SoapUI can all fetch data.

Google Developer can patch or post records with the set_field parameters either in the URL or the body, using any content type you choose.

SoapUI can patch or post records with the set_field parameters in the URL. If these are in the body, they only work if the content type is set to application/x-www-form-urlencoded.

Postman can only patch or post records when the set_field parameters are in the URL. I have not been able to make these work from the body, regardless of which option is chosen e.g. x-www-form-urlencoded, raw, or binary from file. Maybe someone who knows more about Postman will be able to find out why.

Paul Timms

9-14-22

Version 2022-08-01 seems much better in respect of the REST API. We still have one issue with OAuth2, which I believe has been reported and assigned to Erik. During the OAuth2 flow, there's a recommended parameter called "state", described as:

state (recommended)
The state parameter is used by the application to store request-specific data and/or prevent CSRF attacks. The authorization server must return the unmodified state value back to the application.

If the redirect URL is sending this state parameter, it may require it to be sent back from the authorisation server. Currently, the Standard ID authorisation server doesn't support this and sends nothing back, resulting in a failure. As the state parameter is becoming more commonly used, it's important that this functionality is added quickly.

Back to the list

New Message
Open Questions My Questions