Hi Jon,

Once you set http_setAuth(), it will remain set for the duration of the activation group.  So Charles' suggestion is a good one -- by manually un-setting the authentication, you don't have to worry about it being set from a prior call in a different program.

HTTP_AUTH_NONE (no authorization) is the default, however.  So aside from that (potentially unlikely?) scenario where the authorization values are left in the activation group from another program, it would have no effect... it is already the default.

Glad you figured out the problem...

As I mentioned on the FTPAPI list, I would not recommend setting the content-type this way.   GET requests don't usually use a content-type, and for other requests (PUT, POST, etc) that do, if you use the same mechanism, it'll cause two content-type headers to be there (once from HTTPAPI, and once from your code.) Instead, please use HTTPAPI's method of setting the content-type.

-SK


On 5/4/2020 3:54 PM, Jon Paris wrote:
Just to follow up ...

Problem solved - as suspected it was me.

Looking at the log it appeared that the credentials were being passed correctly - but I didn't check closely enough! The back end of the JWT token was being truncated because I had miscounted how big the dang thing was! Increased its size and everything worked.

Just to check Charles I removed the call to http_setAuth(HTTP_AUTH_NONE:'':''); as well and it still works so the "extra" header is apparently not a problem with the current version.

Thanks to both yourself and Brad for the assist and forcing me to look really closely! JWT tokens are a nice simple mechanism but they are so long that visual comparison is impossible.


Jon Paris


On May 4, 2020, at 3:02 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Shouldn't be...

Sure you don't have a typo in the token?

Any chance it's expired?

Charles

On Mon, May 4, 2020 at 12:21 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

The only obvious difference I can see is that the log shows a cookie being
received and an its Id being returned. that does not happen in the HTTPAPI
log.

So I added
http_setOption('use-cookies' : '1');
Just in case cookies were not the default but it makes no difference.

Is there anything else it needs for cookies to work? I'm having a hard
time finding any examples of cookie usage.


On May 4, 2020, at 2:01 PM, B Stone <bvstone@xxxxxxxxx> wrote:

Thanks for the clarification.

Seems that you just need to get HTTPAPI set up properly to send it.

You could compare a raw Postman request (code) with the debugged request
in
HTTPAPI to look for differences. I know others have asked how to sent
Authentication requests before, but since I normally use GETURI I don't
recall specifics.

Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #22 <https://www.bvstools.com/mailtool.html>: Low Total
Cost of Ownership!

On Mon, May 4, 2020 at 12:54 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:
It is a JWT Brad.

Using this curl command on my Mac it works as expected:

curl --request GET
--url https://api.zoom.us/v2/webinars/1234567890/tracking_sources
--header 'authorization: Bearer mySecrtetCodeGoesHere'



I have also run similar code on the Mac in PHP and it works too.

I tried running the same PHP on the IBM i but have certificate issues
then. But HTTPAPI is not reporting any certificate issues and in the
log I
can see the cert exchange.


On May 4, 2020, at 1:35 PM, B Stone <bvstone@xxxxxxxxx> wrote:

Is mySecrtetCodeGoesHere an oauth 2.0 token or a code?

Normally you use your secret code and credentials to exchange for an
OAuth
2.0 token.

Bradley V. Stone
www.bvstools.com
GreenTools for PayPal <https://www.bvstools.com/g4pp.html>: Easily
send
PayPal invoices from your IBM i applications using RPG ILE! Process
refunds, get account balances and more!

On Mon, May 4, 2020 at 12:00 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:
Cross-posted to HTTPAPI and WEB400

I just coded up a basic Zoom API request - this is the basic HTTPAPI
code:
url = 'https://api.zoom.us/v2/webinars/' +
%EditC(webinarId: 'X') +
'/tracking_sources';

headerVars.contentType = 'application/json';

headerVars.authorization = 'Bearer mySecrtetCodeGoesHere';

http_xproc( HTTP_POINT_ADDL_HEADER
: %paddr(addSpecialHeaders)
: %addr(headerVars) );

rc = http_get( url: '/tmp/result.txt' );
if rc <> 1;
http_crash();
endif;


Dcl-Proc addSpecialHeaders;
Dcl-Pi *N;
headersToAdd Varchar(32767);
vars likeds(headerVars) const;
End-Pi;

Dcl-C CRLF x'0d25';

headersToAdd = 'content-type: ' + vars.contentType + CRLF
+ 'authorization: ' + vars.authorization + CRLF;
End-Proc;


This gives me a "401 - This page requires a user-id & password" error

If I copy/paste the credentials and URL into Insomnia and test it - it
works. The user Id stuff is in the "secret key" bit.

Since I copied and pasted this stuff into insomnia from the RPG stuff
I
can only assume I missed a step somewhere. But where?



--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].