Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Request header fields not passed in
I have the authorization header set in Postman but it's not coming through in the request so I keep getting an unauthorised response.
The AdditionalValues are defined in the registry but the actual values aren't found in field 30 of the request.
What might it be that would prevent them from being placed there?
The same request works locally, it's only when I redirect it to the server so it must be a config of some sort.
The AdditionalValues are defined in the registry but the actual values aren't found in field 30 of the request.
What might it be that would prevent them from being placed there?
The same request works locally, it's only when I redirect it to the server so it must be a config of some sort.
Comments
Okay, I'm 99% positive this is IIS swallowing the header for its own use. The same problem occurs with Apache. Both web servers assume you want the web software to manage the authentication. Thus, they take the Authorization header data and attempt to authorize the credentials. Unfortunately, this means they do not opt to pass along the header to your CGI script.
IIS tries to authenticate this through the Windows OS. Apache offers a few options, including a plain text file of usernames and passwords just sitting on the disk!
I know we've gotten IIS to work at least on one site. I just don't recall what we did (Jared...do you recall?). It's possible you just need to disable Basic Authentication in IIS and perhaps this will actually ignore the header and pass it through.
Apache is supposed to have ways of solving this problem but none of the ones I've read and tried have ever worked. So, with Apache we ended up using a custom header (X-Authorization, or HTTP_X_AUTHORIZATION in the registry). This is why the HTTP_Authentication_Services checks for both:
// HTTP Basic uses the Authorization request header. However, the Authorization request header field does not // always work with web server products when being passed to a third-party service. So, if the standard header // returns nothing then check the custom X-Authorization request header. AuthorizationB64 = HTTP_Services('GetRequestHeaderField', 'Authorization') If Len(AuthorizationB64) else AuthorizationB64 = HTTP_Services('GetRequestHeaderField', 'X-Authorization')In a pinch you can just use the custom header with IIS, but I would recommend trying to get the normal header to work.
I thought that I configured both the same but perhaps not.
It's just an issue when it's an external request which is clearly a problem.
I shall continue to dig.
When run from the browser on the server, additional_Values$ contains the values expected.
http_accept$ contains a string like this "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
and oecgi_version$ contains "VERSION:OECGI4"
The corresponding values when the same request is made from another machine are:
Additional_Values$ - null
http_accept$ - "*/*"
oecgi_version$ - "VERSION:OECGI4_"
I don't know what, if any difference those other factors make but I assume they indicate some difference in config somewhere.
Whether it works or not seems dependent or at least related to the endpoint.
I was testing and failing with
api/employees
switched to
api/inet_trace and the header info came through as it also did with
api/clients
api/timecards doesn't bring the header info through though.
working:
api/inet_trace
api/clients
not working
api/employees
api/timecards
All the above are valid. They are all using the same header but consistently show header fields for the working ones and no header fields for the non-working ones.
The "VERSION:OECGI4_" seems to have rectified itself in all cases to just be "VERSION:OECGI4".
I think I'll shut down and revisit tomorrow.
Are you inspecting the request array early, such as in HTTP_MCP before the SetOECGIRequest service, or later? If later, I would suggest that you to inspect the request array before any of the internal services touch it and make changes to it. This way we can positively rule in or out whether IIS is doing something funny with the request based on the end point (which seems very odd to me that it would).
Also, for those end points that appear to be working, do you have an actual web service routine (e.g., HTTP_CLIENTS_SERVICES)? I assume you don't have an HTTP_INET_TRACE_SERVICES
inet_trace is a local gosub in entry_point_services.
Each of the others have their own service.
Only those that carry the header values through actually get that far though.
The other two don't get past http_authentication_services because the authorization header doesn't exist.
It seems to be only when I use postman across the network.
As I typed that I thought to check from my browser and the values are passed in so I'm guessing there must be something awry about my postman call though I can't see what. I'm only changing the endpoint and resending.
You mentioned that testing from a browser on the server works. Does that include Postman? I can't help but think that the odd formatting of the OECGI_VERSION$ value is pointing to corrupted data in transit.
Don't yet have postman on the server but will get to that.
The oecgi_version seems to have resolved itself now so there are no other obvious symptoms.
In other words if I change the Basic Authorisation to No Auth and remove the Authorization header, the "From Postman on Laptop" picture looks like the "From browser on server" picture.
If I call one of the working endpoints such as "clients" for example, then the image looks like the "From browser on server" picture with the addition of the authorization values in field 30.
Sometimes I get a 502.2 Bad Gateway error returned. I was thinking this was a different problem that I would address later.
I might try troubleshooting down that path and see what I find.
When you are testing from a browser, how are you doing this? Are you just entering the URL into the address bar? Thus, is it fair to say that you are not passing in the Authorization header when using the browser as a client?
IIS report 500 errors frequently? Well that's disappointing.
Given that the browser tests were really just Postman tests without the Authorization header, I think we can confidently conclude that there is nothing magical happening with the browser. Hence, you can go back to testing with Postman. The questions I would want to answer are as follows:
Any and all the symptoms occur only when the endpoint is nine characters long. It doesn't matter what it is, just how long it is. The two that were failing for me were /employees and /timecards. Both nine characters. Add or remove a character to either of these and all works as expected.
Note this problem occurs whether these points are the endpoints or if there is more to the url such as a resource id.
So api/employees/id will have the same problem as api/employees.
api/employeesn/id will have the same success as api/employeesn (except of course that it's not a valid service but it still gets through correctly)
Honestly, I had considered this to be a length issue, but thought it was a maximum length issue rather than a specific length issue. So I overlooked the pattern you finally discovered.
This also makes more sense of the anomalous values you are getting. It seems like there is a string size getting maligned, which is why the OECGI version had an extra character (at least at one time).
I hate to think this is OECGI4.exe related, but perhaps swapping it out with OECGI3.exe (I think you could rename OECGI3.exe to OECGI4.exe so your URLs would be the same) would give some quick peace of mind on this subject.
Is there a maximum length issue you've come across before?
No, nothing I have come across. However, if IIS encountered such a problem, I would expect it to return a 414 error.
Are you convinced this is an IIS issue or are you still considering other causes? If you wanted to rule in/out IIS, I recommend you install Abyss and test it under the same conditions. Abyss is free (for what you need it for), is easy to install and configure, and lightweight.
May try Abyss on Monday but happy with using X-Authorization for the time being so I can just get some more runs on the board
As this is early testing stages and the IT guys aren't yet prepared to open up the server, I'm using ngrok to create a secure tunnel.
I'm beginning to think it's possibly a contributing factor.
It's a great tool unless it's causing the problems I'm having. :(
http://localhost/api/employees
worked which then pointed to ngrok definitely being the culprit.
Until that was, I tried the same url again and accidentally passed in the exact same Authorization header twice.
Then the old symptoms returned with no ngrok in sight.
Well similar symptoms anyway. Sometimes the bad gateway error. Sometimes it made it through but the header values while not missing (both Authorization ones were there) but the ones following were screwed up.
Back to the drawing board.