Authorization returning null

AusMarkB

Was testing a new local environment the other day and kept getting an unauthorised response.
Worked through it step by step, for example hadn't added the AdditionalValues into the registry.

Once that was all said and done though, whilst debugging, I could see the request, I could see the AdditionalValues including the Authorization but in http_authentication_services the
AuthorizationB64 = HTTP_Services('GetRequestHeaderField', 'Authorization')
was returning null as was the subsequent check for 'X-Authorization'.

In this case I could see that it didn't get blocked by IIS or anything else because the header was visible in the request. Any thoughts on why the call the http_services to get the value would return null?

DonBakke

Are you also logging the requests? If so, can you email me one of the logs that you believe has the proper information within the Authorization header?

AusMarkB

Don, you crack me up. You didn't think I was going to make it that easy for you did you?

Actually not my laptop and no logging wasn't turned on so

DonBakke

Do you have at-will access to the server (or machine running the OI system) or did you only have a short window of access and what you've shared is about all we can expect to see for now?

AusMarkB

the latter.

I'll have access again next week but it was a low priority last minute "let's see if we can get this to work before we take off home" type scenario.

I'll debug and log further next week if we can prioritise the time. Really just throwing this out there in case anything readily came to mind and a null AuthorizationB64 value was the last thing I saw before we packed up.

Well actually I saw it, which triggered the light bulb that we hadn't added AdditionalValues to the registry so we did that and saw the values come through but still got null.

I'll debug the setrequestheaderfields logic next time and see if the answer presents itself.

DonBakke

Yeah, nothing quick comes to mind because it either works or it doesn't. That's why I wanted to see the log. It would give me (and you) a clearer idea as to how the request data is coming into the Framework.

DonBakke

One wild guess was perhaps case sensitivity with the name of the header field. I'm not looking at the Framework code right now, but I suppose it could fail it is case sensitive.

AusMarkB

No you were smarter than that at the time. Case sensitivity is not a thing.


…. not to say you're not still smarter than that but...

AusMarkB

Just had an opportunity to get back to this and found myself to blame.
Some time ago I changed http_services so that the oecgiRegKey is dynamic so far as which version of the oecgi you were using.
Unfortunately that means that if you're using oecgi4 but your env record says you're using oecgi3 the registry won't be read and the SetRequestHeaderFields won't know to store your additionalValues away. Don't store them away, can't read them later.

Somehow I don't think you would have found that one Don.

Is Don. Is Good.

but you're not that good that you could imagine the mods I made two and a half years ago and couldn't remember myself.

DonBakke

Thanks for the update and self-deprecating humor. Just out of curiosity, what version of the HTTP Framework is running at this site.?

AusMarkB

an early one no doubt as that was MD's dev machine and he hasn't really played with that area.

That said, I haven't really updated it anywhere in production either. Can't remember how to check.

DonBakke

v2 and later there is a SYSENV row with Key ID SRP_HTTP_FRAMEWORK_VERSION. v1 didn't have any identifying marks, so if that row is missing then it is most likely v1.

AusMarkB

Now that you mention that, I did see the version record in MD's sysenv though I didn't look at the content.
In production it must be v1