Hi Rick,

I have a customer hitting my WC app (API) from their production site for the first time. During their development process they were getting the expected response from my API. On their production site, however, they say they are getting a 500 Status with no response.

The IIS log shows a status of 200 with 11781 bytes returned.

The difference I see between the requests from their dev site and their production site is the User-Agent.

From their dev site (which works), the User Agent is Mozilla/4.0+(compatible;+Win32;+WinHttp.WinHttpRequest.5) or some variation thereof.
From their production site, the User Agent is PostmanRuntime/7.13.0.

I am not familiar with Postman-Runtime (like, at all) but it looks like a Javascript Library.

There are two concerns here...

1. The API key is passed in the Authorization header and, if that's being handled in Javascript, that's a security issue, is it not?
2. Apart from that, something is causing a 500 status at their end and I don't understand what's happening.

If you could shed some light on this for me, I'd appreciate it.

Thanks,
Carl

From their production site, the User Agent is PostmanRuntime/7.13.0.

You should be able to change the User Agent as part of the request headers you send, so you can 'fake' the request coming from a specific browser.

However - if IIS is indeed reporting that it returned a response, then the 500 error you are getting is potentially coming from a proxy or something else that sits in between the connection.

It could be that a proxy is rejecting the credentials in the header.

If you can test this - run the request in postman and then look at the actual connection traces in Fiddler or other HTTP capture tool. See whether the 500 error is from a proxy - something other than IIS (IIS puts headers into the response).

The API key is passed in the Authorization header and, if that's being handled in Javascript, that's a security issue, is it not?

That depends what's in the header. Typically an auth header has a timeout so it's only good for a limited time (if it's something like a Bearer token, or Windows Auth Token).

+++ Rick ---

Thanks Rick,

I have no control on the client side so can't do any testing from that end.

It looks like the browser is blocking the response because it is a cross-origin request.
I guess that is not enforced in the dev environment so they didn't have this issue until testing in production.

Regarding the Authorization Key passed in the Authorization header...

That depends what's in the header. Typically an auth header has a timeout so it's only good for a limited time (if it's something like a Bearer token, or Windows Auth Token).

If the request is made in JavaScript, their Authorization Key would be exposed to voyeurs using browser dev tools would it not?
Seems to me that making the request from their server rather than from the browser would be a better practice in order to keep the Authorization Key secret. Or am I misunderstanding something?

Thanks,
Carl

Make sure that CORS is enabled in the application. There's code in the generated process class template that turns this on. One of the CORS headers is to allow credentials.

Look in yourProcess.prg in the OnProcessInit().

+++ Rick ---

There's code in the generated process class template that turns this on. One of the CORS headers is to allow credentials.

Yes, I'm aware of that but I'm concerned about exposing the Authorization Key.

Obviously, if the client is going to insist on making the request in JavaScript, then CORS will need to be enabled.
But would it not be a better practice to suggest to the client to make the request from the server rather than from the browser in order to keep the Authorization Key secret?

Thanks.

What authorization key are you talking about? Authorization for a service you're calling, or the application from a JavaScript front end?

In an application a bearer token authorization header is commonly sent and that expires.

For a remote service it depends on what the authorization is - if it's a token you received after logging in then that can be sent over the wire because it's got a timeout. If it's a raw authentication or API key etc. then yes you'll want to hide that and make that request from the server and not the client.

+++ Rick ---

If it's a raw authentication or API key etc. then yes you'll want to hide that and make that request from the server and not the client.

Yep, that's it.
I've already made that recommendation to the client but I wanted to make sure I was right.

Thanks.