Hi Ron,

> On 08.10.2018, at 23:05, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2018-10-08, at 3:04 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> 
>> Just for completeness sake, If your server gives you a 401 but Not a WWW-Authenticat, they're doing it wrong:
>> 
>> 	https://tools.ietf.org/html/rfc7235#section-4.1
>> 	"A server generating a 401 (Unauthorized) response MUST send a
>> 	 WWW-Authenticate header field containing at least one challenge"
>> 
>> On the other hand, the 401-before-Authenticat is the norm but not RFC required:
>> 
>> 	https://tools.ietf.org/html/rfc7235#section-4.2
>> 	"The "Authorization" header field allows a user agent to authenticate
>> 	itself with an origin server -- usually, but not necessarily, after
>> 	receiving a 401 (Unauthorized) response. "
> 
> So it must do it but it is optional? Sounds about right for 'standards' {insert obligatory xkcd reference url} on the web.


Nah. Top is for server (that generates a 401), bottom is for client (that MAY receive a 401).

So we are a bit wrong, but the server is wronger™. Not sending the header but making 401 is baad.
Strangely, their current code looks correct-ish. What version does that have? because: 

	https://github.com/woocommerce/woocommerce/commit/98f4f2110425e96438a6230efedcfb88945d89ad

apparently introduced the header in v3.5 or so...

> 
> The practical issue is that WooCommerce is a very common thing and unless I've managed to mess something up (certainly not impossible in this case) it simply doesn't do what it is supposed to. There's quite a lot about this issue around the web, for what it's worth.

Yea, apparently it is not easy to configure front-servers (Aka reverse-proxys) to correctly pass headers around.
It seems to be so common that they include things like that in the documentation:
	"Occasionally some servers may not parse the Authorization header correctly (if you see a “Consumer key is missing” error when authenticating over SSL, you have a server issue). In this case, you may provide the consumer key/secret as query string parameters instead."
	(https://woocommerce.github.io/woocommerce-rest-api-docs/#authentication-over-https)


> 
> For an example, using the Postman application to avoid any possible problems in my squeak - 
> do a GET with https://astropicase.com/wp-json/wc/v2/products and no auth.
> The response body is 
> {"code":"woocommerce_rest_cannot_view","message":"Sorry, you cannot list resources.","data":{"status":401}}
> and the listing of headers has no mention of any WWW-Authenticate or similar.
> 
> 
> Interestingly some woocommerce documentation writes about doing the right thing -
> http://woocommerce.wp-a2z.org/oik_api/wc_api_authenticationexit_with_unauthorized_headers/
> but I don't see anything that makes me understand why it isn't apparently being used.
> 

It may be also a version thing. see above.

> Perhaps there is some configuration setting buried in there  - but one of the classic problems is the way that any area of endeavour ends up with its own idioms and assumed knowledge and until you know a lot of it you don't know enough to be able to ask intelligent questions to help you get to know any of it.

Yep. Entry vocabulary. Its especially strange in this rest-api setting (wth is a Bearer?)

> So I'm pretty lost in much of this and I really don't want to be an expert anyway since there is already way too much to do.

Too true.

> 
>> However, proactively sending Authorization-headers is a grave security issue. It Should Not Be Done.
> 
> I'm interested; why do you say this?

Because its like running around with your credit card and putting it in every slot available _just_ because you know one of the machines you come by you want to buy something from.

See:

I can connect to my server like so:
% curl -v https://netshed.de
* Rebuilt URL to: https://netshed.de/
*   Trying 185.244.192.218...
* Connected to netshed.de (185.244.192.218) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: netshed.de
* Server certificate: Let's Encrypt Authority X3
* Server certificate: DST Root CA X3
> GET / HTTP/1.1
> Host: netshed.de
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 08 Oct 2018 21:54:09 GMT
< Content-Type: text/html
< Content-Length: 114
< Last-Modified: Tue, 29 May 2018 20:41:54 GMT
< Connection: keep-alive
< ETag: "5b0dbb12-72"
< X-Clacks-Overhead: GNU Terry Pratchett
< Accept-Ranges: bytes
<
<DOCTYPE html>
<html lang="tlh">
<head><title>netshed.de</title>
</head>
<body>
<p>netshed.de</p>
</body>
</html>

===> I get some document back

But If i include credentials proactively:

% curl -v -u foo:bar https://netshed.de
* Rebuilt URL to: https://netshed.de/
*   Trying 185.244.192.218...
* Connected to netshed.de (185.244.192.218) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: netshed.de
* Server certificate: Let's Encrypt Authority X3
* Server certificate: DST Root CA X3
* Server auth using Basic with user 'foo'
> GET / HTTP/1.1
> Host: netshed.de
> Authorization: Basic Zm9vOmJhcg==
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 08 Oct 2018 21:52:13 GMT
< Content-Type: text/html
< Content-Length: 114
< Last-Modified: Tue, 29 May 2018 20:41:54 GMT
< Connection: keep-alive
< ETag: "5b0dbb12-72"
< X-Clacks-Overhead: GNU Terry Pratchett
< Accept-Ranges: bytes
<
<DOCTYPE html>
<html lang="tlh">
<head><title>netshed.de</title>
</head>
<body>
<p>netshed.de</p>
</body>
</html>

Nothing changes, EXCEPT that side did not need that information but now has it. 
I wrote that myself so I know nothing will happen there, yet, the principle of minimal knowledge still applies.


HTH
	-Tobias

> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Rules for Optimization: 1. Don't; 2. (for experts only) Don't Yet
> 
> 
> 
> 
>