https & woocommerce; basicAuth etc?
Locked
https & woocommerce; basicAuth etc?
 
|
I'm trying to be able to access my WooCommerce plugin stuff from Squeak and it's tantalisingly close to working. Part of the problem is that I'm just not very familiar with how http socketty stuff works - enough that I'm sure I don't know the right things to search for to get where I want.
I *can* talk to the 'software add-on' to woocommerce and do things like generate software keys, check validity etc. which is good; it shows that I can get through using https (at least I think so - debugging seems to indicate SSL getting used and checked) BUT I can't do the more basic WC stuff that requires some authorisation. I'll admit that it puzzles me that the add-on doesn't need authorisation but that's how it works. So, can anyone point me to info or code that handles the 'basicAuth' - or indeed any other authorisation - for http sockets? A guide of the level of 'http sockets and authorisation for dummies' wouldn't hurt either! I did spot 'zinc' whilst floundering around. It seems rather old, and that doesn't necessarily mean bad but may mean borken enough to not work in any recent image. It might even have already been folded in? Help me Obi-Woo Commercebi, you're my only socket! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: ESC: Emulate Small Child |
|
|
Are you using WebClient? It is actually documented int he help system, check it out, especially the Authentication section. It does basic and digest authentication, apparently. -cbc On Mon, Oct 1, 2018 at 10:59 AM tim Rowledge <[hidden email]> wrote: I'm trying to be able to access my WooCommerce plugin stuff from Squeak and it's tantalisingly close to working. Part of the problem is that I'm just not very familiar with how http socketty stuff works - enough that I'm sure I don't know the right things to search for to get where I want. |
Re: https & woocommerce; basicAuth etc?
|
|
> On 2018-10-01, at 1:01 PM, Chris Cunningham <[hidden email]> wrote: > > Are you using WebClient? It is actually documented int he help system, check it out, especially the Authentication section. It does basic and digest authentication, apparently. Sigh. I looked at the help, having noticed that webclient/server was one of the too few facilities with decent help some time ago. And I looked *right past* the bit I needed. Nurse! Bring me some new dried frog pills! More germanely, the webclient seems to want to do a request without any authorisation stuff, get back a '401' and retry with some authorisation - but from quickly debugging, WebClient>>#authenticate:from: is expecting a 'WWW-Authenticate' header section that simply isn't there. That would get used to choose the auth method. I haven't seen anything that makes me think I can force the woocommerce stuff to provide that header data. No idea if it is really a good scheme to rely upon it. I suspect I can make up a way to do a more direct use-auth-first-time approach that might be better when you know it has to have it. After my frog pills... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SFA: Seek Financial Assistance |
Re: https & woocommerce; basicAuth etc?
|
|
Hi Tim, Here are the basics: https://en.wikipedia.org/wiki/Digest_access_authentication What did you get back from on the 401? Check headers on WebResponse. Are you behind a proxy server? Maybe Proxy-Authenticate. All the best, Ron On Mon, Oct 1, 2018 at 4:30 PM tim Rowledge <[hidden email]> wrote:
|
Re: https & woocommerce; basicAuth etc?
|
|
Hey Tim, Did you see this: https://medium.com/@avyatech/how-to-authenticate-woocommerce-app-user-e76187423bba All the best, Ron On Mon, Oct 1, 2018 at 5:19 PM Ron Teitelbaum <[hidden email]> wrote:
|
Re: https & woocommerce; basicAuth etc?
|
|
In reply to this post by timrowledge
On Mon, 1 Oct 2018, tim Rowledge wrote:
> > >> On 2018-10-01, at 1:01 PM, Chris Cunningham <[hidden email]> wrote: >> >> Are you using WebClient? It is actually documented int he help system, check it out, especially the Authentication section. It does basic and digest authentication, apparently. > > Sigh. I looked at the help, having noticed that webclient/server was one of the too few facilities with decent help some time ago. And I looked *right past* the bit I needed. > > Nurse! Bring me some new dried frog pills! > > More germanely, the webclient seems to want to do a request without any authorisation stuff, get back a '401' and retry with some authorisation - but from quickly debugging, WebClient>>#authenticate:from: is expecting a 'WWW-Authenticate' header section that simply isn't there. That would get used to choose the auth method. I haven't seen anything that makes me think I can force the woocommerce stuff to provide that header data. No idea if it is really a good scheme to rely upon it. > > I suspect I can make up a way to do a more direct use-auth-first-time approach that might be better when you know it has to have it. After my frog pills... Yes you can. You just have to add the Authorization header yourself. Adding basic auth manually to the example in help would look something like this: | client username password response | client := WebClient new. username := 'Tim'. password := 'secret'. response := client httpGet: 'http://www.squeak.org/protected' do: [ :request | request headerAt: 'Authorization' put: 'Basic ', (username, ':', password) base64Encoded ]. response content. "Prefetch response body before closing the client." client close. "Do not let WebClient instances leak external semaphores." ^response Levente > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: SFA: Seek Financial Assistance |
Re: https & woocommerce; basicAuth etc?
|
|
In reply to this post by Ron Teitelbaum
> On 2018-10-01, at 2:19 PM, Ron Teitelbaum <[hidden email]> wrote: > > Hi Tim, > > Here are the basics: https://en.wikipedia.org/wiki/Digest_access_authentication Interesting; it even seems like a good idea. I'd never have thought of looking for 'digest authentication'! > > What did you get back from on the 401? Check headers on WebResponse. an OrderedCollection('server'->'nginx/1.14.0' 'date'->'Mon, 01 Oct 2018 21:23:35 GMT' 'content-type'->'application/json; charset=UTF-8' 'transfer-encoding'->'chunked' 'connection'->'keep-alive' 'expires'->'Wed, 11 Jan 1984 05:00:00 GMT' 'cache-control'->'no-cache, must-revalidate, max-age=0' 'x-robots-tag'->'noindex' 'link'->'<https://astropicase.com/wp-json/>; rel="https://api.w.org/"' 'x-content-type-options'->'nosniff' 'access-control-expose-headers'->'X-WP-Total, X-WP-TotalPages' 'access-control-allow-headers'->'Authorization, Content-Type' 'x-endurance-cache-level'->'2') No 'WWW-Authenticate' entry to trigger the auth process. > > Are you behind a proxy server? Maybe Proxy-Authenticate. Not so far as I know or can tell. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Compromise, says Prof. Trefusis, is stalling between two fools |
Re: https & woocommerce; basicAuth etc?
|
|
In reply to this post by Ron Teitelbaum
> On 2018-10-01, at 2:22 PM, Ron Teitelbaum <[hidden email]> wrote: > > Hey Tim, > > Did you see this: https://medium.com/@avyatech/how-to-authenticate-woocommerce-app-user-e76187423bba Not specifically, though plenty of similar stuff that hasn't yet gelled. The problem is that lots of articles show some of it but not all and it takes a lot of reading before any pattern starts to emerge. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: MTP: MounT Programmer |
Re: https & woocommerce; basicAuth etc?
|
|
In reply to this post by timrowledge
Hi Tim, Yeah, I think you need to get the token first using the API. See the link I sent, It doesn't look too bad. On Mon, Oct 1, 2018 at 5:36 PM tim Rowledge <[hidden email]> wrote:
|
Re: https & woocommerce; basicAuth etc?
|
|
In reply to this post by Levente Uzonyi
Yay! Winner!
> On 2018-10-01, at 2:30 PM, Levente Uzonyi <[hidden email]> wrote: > > On Mon, 1 Oct 2018, tim Rowledge wrote: > >> >> I suspect I can make up a way to do a more direct use-auth-first-time approach that might be better when you know it has to have it. After my frog pills... > > Yes you can. You just have to add the Authorization header yourself. Adding basic auth manually to the example in help would look something like this: > > | client username password response | > client := WebClient new. > username := 'Tim'. > password := 'secret'. > response := client httpGet: 'http://www.squeak.org/protected' do: [ :request | > request headerAt: 'Authorization' put: 'Basic ', (username, ':', password) base64Encoded ]. > response content. "Prefetch response body before closing the client." > client close. "Do not let WebClient instances leak external semaphores." > ^response I saw the httpGet:do: but hadn't a clue how to assemble the header bit. Thank you! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Law of Logical Argument: Anything is possible if you don't know what you are talking about. |
Re: https & woocommerce; basicAuth etc?
|
|
Woohoo, what does he win Jonny'O! Ron On Mon, Oct 1, 2018 at 5:45 PM tim Rowledge <[hidden email]> wrote: Yay! Winner! |
Re: https & woocommerce; basicAuth etc?
|
|
> On 2018-10-01, at 2:53 PM, Ron Teitelbaum <[hidden email]> wrote: > > Woohoo, what does he win Jonny'O! Gaaaah. I had a long email explaining that it wasn't *quite* working since a second site I need to connect to was failing, how I'd turned on ssl logging, compared the logs, convinced my self that it wasn't the slightly odd certificate CN value screwing things up.... and then I discovered I pasted the wrong damn uid/pwd for the second site. With the right ones it works. Sigh. So Levente's chief prize is that he gets confirmation that he isn't as senile as me. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Radix lecti = Couch potato |
Re: https & woocommerce; basicAuth etc?
|
|
In reply to this post by timrowledge
Hi all
> On 01.10.2018, at 23:45, tim Rowledge <[hidden email]> wrote: > > Yay! Winner! > >> On 2018-10-01, at 2:30 PM, Levente Uzonyi <[hidden email]> wrote: >> >> On Mon, 1 Oct 2018, tim Rowledge wrote: >> >>> >>> I suspect I can make up a way to do a more direct use-auth-first-time approach that might be better when you know it has to have it. After my frog pills... >> >> Yes you can. You just have to add the Authorization header yourself. Adding basic auth manually to the example in help would look something like this: >> >> | client username password response | >> client := WebClient new. >> username := 'Tim'. >> password := 'secret'. >> response := client httpGet: 'http://www.squeak.org/protected' do: [ :request | >> request headerAt: 'Authorization' put: 'Basic ', (username, ':', password) base64Encoded ]. >> response content. "Prefetch response body before closing the client." >> client close. "Do not let WebClient instances leak external semaphores." >> ^response > > I saw the httpGet:do: but hadn't a clue how to assemble the header bit. Thank you! 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. " However, proactively sending Authorization-headers is a grave security issue. It Should Not Be Done. Hence, I think WebClient's variant is ok. That being said, maybe we can introdue a proactive auth flag. Best regards -Tobias |
Re: https & woocommerce; basicAuth etc?
|
|
> On 2018-10-08, at 3:04 AM, Tobias Pape <[hidden email]> 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. 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. 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. 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. 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. > However, proactively sending Authorization-headers is a grave security issue. It Should Not Be Done. I'm interested; why do you say this? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Rules for Optimization: 1. Don't; 2. (for experts only) Don't Yet |
Re: https & woocommerce; basicAuth etc?
|
|
Hi Ron,
> On 08.10.2018, at 23:05, tim Rowledge <[hidden email]> wrote: > > > >> On 2018-10-08, at 3:04 AM, Tobias Pape <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Rules for Optimization: 1. Don't; 2. (for experts only) Don't Yet > > > > > |
Re: https & woocommerce; basicAuth etc?
|
|
> On 2018-10-08, at 3:01 PM, Tobias Pape <[hidden email]> wrote: > > Hi Ron, > Ron? Who Ron? Not me... ;-) > > 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... Now that is weird. I know the WC plugin was updated just a week or so ago but it is apparently only 3.4.4 And to make it more interesting that commit was dated in 2016! I'll get sysadmin to update *again*. >> 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) Yup, it annoys me on a regular basis over the recent past. > Yep. Entry vocabulary. Its especially strange in this rest-api setting (wth is a Bearer?) I can only think it is something to do with Winnie the Pooh. >>> 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. Oh, I get your point. Promiscuously sticking your bits in any available socket may get you an infection. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Got into the gene pool while the lifeguard wasn't watching. |
Re: https & woocommerce; basicAuth etc?
|
|
Hi,
> On 09.10.2018, at 02:41, tim Rowledge <[hidden email]> wrote: > > > >> On 2018-10-08, at 3:01 PM, Tobias Pape <[hidden email]> wrote: >> >> Hi Ron, >> > > Ron? Who Ron? Not me... ;-) > Yea sorry tim. I recently wrote to ron. Maybe prophecy? Maybe you should chat with Ron? :D >> >> 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... > > Now that is weird. I know the WC plugin was updated just a week or so ago but it is apparently only 3.4.4 And to make it more interesting that commit was dated in 2016! I'll get sysadmin to update *again*. Versions are sooo fun. > > >>> 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) > > Yup, it annoys me on a regular basis over the recent past. > >> Yep. Entry vocabulary. Its especially strange in this rest-api setting (wth is a Bearer?) > > I can only think it is something to do with Winnie the Pooh. That would be more fund than https://tools.ietf.org/html/rfc6750 actually. > > >>>> 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. > > Oh, I get your point. Promiscuously sticking your bits in any available socket may get you an infection Well said. Best regards -Tobias |
Re: https & woocommerce; basicAuth etc?
|
|
Interesting side-comment about WooCommerce versions - the 3.5 stuff with the corrected (we hope) WWW-Auth header return is only just in RC1 release. So it's taken over 2 years to get from the putative fix being committed to it being released!
tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Programming is an art form that fights back. |
Re: https & woocommerce; basicAuth etc?
|
|
> On 09.10.2018, at 18:58, tim Rowledge <[hidden email]> wrote: > > Interesting side-comment about WooCommerce versions - the 3.5 stuff with the corrected (we hope) WWW-Auth header return is only just in RC1 release. So it's taken over 2 years to get from the putative fix being committed to it being released! That's almost our release cycle! :D > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Programming is an art form that fights back. > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |