GWGWatching [tantek] and [schmarty] demo at IWC Berlin 2018 because I was looking at archives and they did some archive navigation stuff. Alas, the pagination session does not seem to be recorded
[manton]@GWG Hmm. This is a pretty basic WordPress blog, other than I installed a plug-in to disable the RSD/XML-RPC link tags. Have you seen that problem before?
[manton]@GWG Related to Apache, I noticed that mod_security is enabled (this is hosted on an old DreamHost account). I’ve disabled it if you want to try again.
ZegnatAlternatively there could be some sort of whitelisting shenanigans going on where the test is bypassing mod_sec because it is originating on the same server?
ZegnatCould we add a debugging endpoint somewhere (disabled by default) that simply returns the authorization header value? I think that might go a long way.
ZegnatMaybe I should also do a JS version of the header checking script. So the requests are made by the browser and it validates whether an external client can use authorization headers.
[manton]I did try passing access_token as a parameter too (to Micropub q=config), so my issue doesn’t appear to be specifically with the HTTP header, unless I did something else wrong with my test.
ZegnatAccess token verification does not support that parameter, I think? Unless that is something WP has added. So if that step is failing, there is probably something else getting borked
[manton]Oh sorry, I was mixing 2 separate issues. What GWG is testing is slightly different than what I ran into. I got what looks like a valid token, but making any Micropub requests with it returns a 403 error.
ZegnatFine if you are sideloading for debugging. Just felt like it should be said that HTTP headers are client-provided-data and you should not normally just echo that always. Means you need to start thinking about XSS and all that crap if it is public-by-default
ZegnatI wonder what the output is if you run the curl command above straight on the box. Then maybe they are doing something funky where Authorization headers are let through within the box, but not from outside their network.
ZegnatThis feels closer to a Dreamhost issue than a WordPress or IndieAuth issue, to be honest. But I understand the want to give users some sort of feedback on that
ZegnatYou are also dumping the entire $_SERVER global which may include other information. So maybe also do an array_filter and only print those starting with `HTTP_`?
Zegnat$_SERVER also includes environment variables from the server itself, which you may not want to leak. Therefor I would only render names starting with HTTP_, as you are only interested in HTTP headers here.
Loqi[aaronpk] Hi! I was away from my computer the last 2 days, just catching up now. Now that you mention it, I do remember hearing about some web servers removing the `Authorization` header. It could be either the web server or a proxy server in between.
It lo...
ZegnatI guess you could try running my original authdiag on the server and see if it reports correctly? If it does, something broke in the WP implementation