Hey Christoph

> On 12.10.2020, at 21:25, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> 
> Hi Tobias!
> 
> I don't understand your objection. As the link says, some REST APIs will return a 404 Not Found error rather than a 401 Unauthorized error to make sure that unauthorized users cannot know the list of private objects that exist for the owning user.

You're conflating authentication and authorization.
(That said, I think the header name is a misnomer in HTTP…, but I might be wrong)


> For example, the GitHub API will respond with a 404 error if you try to access the following URL without authorization: https://api.github.com/repos/LinqLover/openHAB-configuration/zipball/master
> However, I sweat that this repository actually exists, and I will get a 202 OK response if I authenticate before!
> It's the same pattern as not telling you whether your email or your password is wrong on any web service to protect the knowledge about registered users from possible attackers.


No its different.
Look: if you go to
	https://api.github.com/
One of the json entries is:

	authorizations_url: "https://api.github.com/authorizations"

If you go to 

	"https://api.github.com/authorizations"

You'll get the 401.

From then on, all HTTP Clients will continue with authorization headers.

No preauth required.

If I'm authenticated that way, I as krono will get the 404 on your url, but you as LinqLover will get 200.


And yes, Github essentially says "F$#^#$ Standards":

https://docs.github.com/en/free-pro-team@latest/rest/overview/other-authentication-methods
	The API supports Basic Authentication as defined in RFC2617 with a few slight differences. The main difference is that the RFC requires unauthenticated requests to be answered with 401 Unauthorized responses. In many places, this would disclose the existence of user data. Instead, the GitHub API responds with 404 Not Found. This may cause problems for HTTP libraries that assume a 401 Unauthorized response. The solution is to manually craft the Authorization header.

And I hate it.
They're trading privacy for security. That's a dick move.

NB: For 2FA, you need the https://api.github.com/authorizations endpoint anyways: https://docs.github.com/en/free-pro-team@latest/rest/overview/other-authentication-methods#working-with-two-factor-authentication

So maybe, first going to "https://api.github.com/authorizations" is a good idea in the first place? 

:D

It's not your fault, I understand you just want to get things going.
GitHub is a too big player and we have to scratch standards for that, sigh…


> > I do not support preemtive authentication, especially in non-SSL circumstances.
> 
> Why not?

It leaks credentials unnecessarily.

> However, I would not dislike a warning being raised every time you try to authenticate if the scheme is not https.

WebClient is pretty lean for a HTTP client, I'd rather have it continue that way.

That said, you can simply do

WebClient 
	httpGet: 'https://api.github.com/repos/LinqLover/openHAB-configuration/zipball/master'
	do: [:req | req headerAt: 'Authorization' put: 'WHATEVER-NECESSARY']

And you have your pre-auth.

> 
> > It is also hard to see the differences because you reformatted them method :/
> 
> That's truly a problem ... I found the original method version suboptimal to read. Is the prettyDiffs an option for you? Otherwise, I can split up this inbox version.

I understand that the method is maybe not the most common style, but I think that functional changes should in such cases not be mixed with style changes.


Best regards
	-Tobias

> 
> Best,
> Christoph
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de>
> Gesendet: Montag, 12. Oktober 2020 21:06:21
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] The Inbox: WebClient-Core-ct.126.mcz
>  
> Hi
> 
> > On 12.10.2020, at 20:47, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> > 
> > For example, many modern REST APIs use to return an error 404 if an attempt is made to access a private resource without authenticating before [1] which currrently makes it impossible to authenticate to these APIs using the WebClient.
> 
> 
> No, thats not what the link says:
> 
> Q: "1. How to deal with unauthorized requests?
> 
> I'm intending to respond to requests with the following codes:
> 
>         • Is the resource open and found? 200 OK
>         • Do you need to be authenticated to access the resources? 401 Unauthorized
>         • Don't you have access to a category of resources? 403 Forbidden
>         • Do you have access to a category of resources, but not to this specific resource? 404 Not Found to prevent people from getting to know the existance of a resource they do not have access to.
>         • Doesn't the resource exist? 404 Not Found
> 
> "
> A: "How to deal with unauthorized requests?
> 
> The way you described it is pretty much the recommended way for a RESTful service. As far as I can see there is absolutely nothing wrong with that."
> 
> 
> That means: "Do you need to be authenticated to access the resources? 401 Unauthorized" 
> 
> I do not support preemtive authentication, especially in non-SSL circumstances.
> 
> 
> =-=-=-=
> 
> 
> It is also hard to see the differences because you reformatted them method :/
> 
> Best regards
>         -Tobias