Author Topic: REST problems (Read 3531 times)

James Zukowski · « **on:** September 27, 2023, 10:44:08 AM »

I've been wracking my brain trying to figure out what's going on, with only minor insights. It doesn't help that I don't really have any REST interfacing experience.

We're trying to connect with a service for address validations. There are two steps involved: (1) Get an oauth2 token from them, then (2) submit the actual request using the token. I haven't been able to get to step 2 because of failures in step 1.

Working with someone else in the company, we were able to get a curl command to work:

Code: [Select]

curl --location 'https://example.com/oauth2/vn/token' --header 'Content-Type: application/json' --data '{ "client_id": "xxxxxxxxxxxx", "grant_type": "client_credentials", "scopes": "urn:tr:onesource:auth:api:IndirectTaxDetermination", "client_secret": "xxxxxxxxxxx" }' > /tmp/result.txt

But running the related information through the *plus/web/request, I was ALWAYS receiving a 400 error in response. (Actually, I had to make some adjustments, since it always added ";secure" to the OPEN, and that generated a PxPlus error.) Apparently, we need to be able to submit the request down at the "token" page level, but the *plus/web/request breaks that up, and PxPlus won't accept a filename beyond the primary site (.com).

I would like to keep all of the programming within PxPlus, but if I need to curl things to get them to work, it's what I'll have to do. Any suggestions would be greatly appreciated.

Currently running v15 (2018) with WindX on Linux.

PxPlus · « **Reply #1 on:** September 27, 2023, 11:59:39 AM »

The error 400 indicates:

The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).

What are you passing *plus/web/request?
Have you provided the extra headers in the call?

James Zukowski · « **Reply #2 on:** September 27, 2023, 01:45:03 PM »

Here's the setup (website name changed, but path still there):

Code: [Select]

url$="https://example.com/oauth2/vn/token"
!
postdata$="{"
postdata$+=$0D0A$+"  "+quo+"client_id"+quo+": "+quo+clientID$+quo+","
postdata$+=$0D0A$+"  "+quo+"grant_type"+quo+": "+quo+"client_credentials"+quo+","
postdata$+=$0D0A$+"  "+quo+"scopes"+quo+": "+quo+"urn:tr:onesource:auth:api:IndirectTaxDetermination"+quo+","
postdata$+=$0D0A$+"  "+quo+"client_secret"+quo+": "+quo+clientSecret$+quo
postdata$+=$0D0A$+"}"
!
mimetype$="application/json"
extrahdrs$="Accept: application/json"
!
CALL "*plus/web/request",url$,postdata$,recvdata$,recvhdr$,mimetype$,"",extrahdrs$

I've tried with mimetype$="application/x-www-form-urlencoded". I've tried with and without the extrahdrs$.

We took the variable contents and fed that into the curl, and it worked fine.

All I can figure is that the full path (through /token) needs to be opened on the [TCP] connection, not just the domain (example.com). That doesn't seem to be available with PxPlus, unless I'm not doing something right (which is quite possible).

Thanks for the help!

PxPlus · « **Reply #3 on:** September 27, 2023, 02:00:59 PM »

I just tried the curl command you provided from a Linux box here and received the exact same response as I did when calling *plus/web/request:

[testuser@centos tmp]# curl --location 'https://example.com/oauth2/vn/token' --header 'Content-Type: application/json' --data '{ "client_id": "xxxxxxxxxxxx", "grant_type": "client_credentials", "scopes": "urn:tr:onesource:auth:api:IndirectTaxDetermination", "client_secret": "xxxxxxxxxxx" }' > /tmp/result.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 596 100 433 100 163 1094 412 --:--:-- --:--:-- --:--:-- 1093 [testuser@centos tmp]# cat result.txt <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>404 - Not Found</title> </head> <body> <h1>404 - Not Found</h1> <script type="text/javascript" src="//obj.ac.bcon.ecdns.net/ec_tpm_bcon.js"></script> </body> </html>

Here is what I got using *plus/web/request:

-:?recvdata$ <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>404 - Not Found</title> </head> <body> <h1>404 - Not Found</h1> <script type="text/javascript" src="//obj.ac.bcon.ecdns.net/ec_tpm_bcon.js"></script> </body> </html>

Devon Austen · « **Reply #4 on:** September 27, 2023, 02:06:38 PM »

You said:

Quote

Actually, I had to make some adjustments, since it always added ";secure" to the OPEN, and that generated a PxPlus error.

*plus/web/request is adding the ;secure to the open because it is a HTTPS server. If you modified the program not to do that then it then likely the server rejects the request since it is insecure.

What error where you getting when it did add the ;secure? It is possible OpenSSL is not setup correctly for PxPlus to find it and fixing that will resolve your issue.

How to fix missing OpenSSL Libraries on Linux: https://forum1.pvxplus.com/index.php?topic=495.0

If your Linux distribution is older it also could be possible it doesn't support the minimum SSL/TLS version required by the server you are trying to connect to.

The error message when you attempt with a ;secure should tell you what the issue is. You may need to print msg(-1) for more info.

James Zukowski · « **Reply #5 on:** September 27, 2023, 03:48:40 PM »

As a first step, it could be we've got old libraries linked as the defaults. I've sent a message to our OS team to check into it. Once we have some clarity there, I'll be able to update things here.

Thanks for the pointer.

Devon Austen · « **Reply #6 on:** September 27, 2023, 03:56:56 PM »

From a PxPlus command line can you run:

Code: [Select]

OPEN (1) "[tcp]www.pvxplus.com;443;secure"
That will at least tell you if OpenSSL is working and if not should give you an error pointing to the issue.

James Zukowski · « **Reply #7 on:** September 27, 2023, 05:07:18 PM »

It's responding:

Quote

Error #13: File access mode invalid
Last IO to [tcp]www.pvxplus.com;443;secure, channel 1

but no reference to the libraries.

PxPlus · « **Reply #8 on:** September 27, 2023, 06:51:31 PM »

Did you print what was in MSG(-1) to see what OS error you are receiving?

James Zukowski · « **Reply #9 on:** September 28, 2023, 09:21:10 AM »

No, I didn't. But our systems guys updated some outdated links and it looks like all is well.

Thanks, all, for the help. GREATLY appreciated!

Stéphane Devouard · « **Reply #10 on:** September 30, 2023, 03:14:36 AM »

James

You don't have to build postdata$ if the API server accepts JSON

You can use PxPlus internal conversion of hash tables to JSON

Code: [Select]

postdata$["client_id"]=clientID$
postdata$["grant_type"]="client_credentials"
postdata$["scopes"]="urn:tr:onesource:auth:api:IndirectTaxDetermination"
postdata$["client_secret"]=clientSecret$
postdata$=DIM(LIST EDIT postdata${all})

James Zukowski · « **Reply #11 on:** October 02, 2023, 10:32:38 AM »

Thanks, Stéphane! That's a real sweet way to do it.

It's great to learn something new every day!

Author Topic: REST problems (Read 3531 times)

James Zukowski

REST problems

PxPlus

Re: REST problems

James Zukowski

Re: REST problems

PxPlus

Re: REST problems

Devon Austen

Re: REST problems

James Zukowski

Re: REST problems

Devon Austen

Re: REST problems

James Zukowski

Re: REST problems

PxPlus

Re: REST problems

James Zukowski

Re: REST problems

Stéphane Devouard

Re: REST problems

James Zukowski

Re: REST problems