scottklement.com

Posted: **Tue Mar 22, 2022 7:56 pm**

I have a *SRVPGM that downloads PDF files from an Azure environment. The environment requires no authentication. The code hasn't changed in months or years. Starting Sunday morning, one particular user starting getting HTTP 403 responses. All other users continue to function, even downloading PDF files from the same URLs. Our IT department, who's responsible for the Azure environment, swears nothing has changed.

I updated HTTPAPI (1.32 -> 1.45), but the issue persisted (I figured it couldn't hurt to get current). I set http_debug() and compared logs between the problem user and other users. Cookies are the one thing that jumps out at me. This process shouldn't be using cookies. The problem user shows this:

Code: Select all

Protocol Used: TLS Version 1.2
http_persist_get(): entered
http_persist_req(GET) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(GET): entered
There are 1 cookies in the cache
cookie=siteDC not sent (wrong path or domain)

This shows up on the first call within the job, so I don't know where the cached cookies are coming from. As I understand the code, unless an IFS file is specified for caching, cookies are stored in the activation group.

While working users all show:

Code: Select all

There are 0 cookies in the cache

I can turn off cookies and see what happens, but I don't like leaving things like this hanging.

Any ideas on what to check?

TIA

Posted: **Wed Mar 23, 2022 3:28 pm**

I explicitly turned off cookies, but the underlying issue persists. The cookies may be another symptom of the actual issue or a red herring.

Here's the actual procedure call:

Code: Select all

rc = http_url_get(lFileURL :lPdf);

The log for the failing user shows Authorization, which shouldn't be there.

Code: Select all

Protocol Used: TLS Version 1.2
http_persist_get(): entered
http_persist_req(GET) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(GET): entered
GET url_path_here HTTP/1.1
Host: hostname_here
User-Agent: http-api/1.45
Authorization: Basic ...


recvresp(): entered
HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

Here's the sample snippet from a working user:

Code: Select all

Protocol Used: TLS Version 1.2
http_persist_get(): entered
http_persist_req(GET) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(GET): entered
There are 0 cookies in the cache
GET url_path_here  HTTP/1.1
Host: hostname_here
User-Agent: http-api/1.45


recvresp(): entered
HTTP/1.1 200 OK

This has been working for about a year before inexplicably breaking Sunday morning.

Posted: **Wed Mar 23, 2022 4:42 pm**

I'm not understand what this has to do with cookies?

His userid/password isn't being accepted by the server.

Also, please note that you just posted his userid/password to a public web page, viewable by everyone in the world. I guess its fine in this situation since that userid/password doesn't work, anyway? But, I would definitely make sure its changed -- since you just posted it to the public, anyone/everyone could have it.

Posted: **Thu Mar 24, 2022 1:56 pm**

There shouldn't be cookies, and the problem user showed cookies in the log. That's why I started off looking at the cookies.

There shouldn't be any authentication, so I don't know what it's doing there. The program doesn't specify any authentication, so where would the credentials come from?

Edit:
I decoded the credentials and found them in a seemingly unrelated *SRVPGM, which was not setting HTTP_AUTH_NONE. I changed the password and added HTTP_AUTH_NONE in On-Exit.

Thank you so much

Posted: **Fri Mar 25, 2022 12:23 am**

Did removing the credentials solve the problem for you?

scottklement.com

Mystery cookie cache

Mystery cookie cache

Re: Mystery cookie cache

Re: Mystery cookie cache

Re: Mystery cookie cache

Re: Mystery cookie cache