Hi Tobias,


okay, I see this authorization pattern now, so you mentioned two ways to work around the current limitations:

First, by GETting https://api.github.com/authorizations before, or second, by passing the Authorization header manually.

Is this correct?


However, both of these approaches lack of the RESTful-typical simplicity of "making a single HTTP request without dealing with complex call protocols or low-level connectivity code". To give an illustration of my use case, please see this PR on Metacello: https://github.com/Metacello/metacello/pull/534

IMHO it would be a shame if you could not access a popular REST API like api.github.com in Squeak using a single message send to the WebClient/WebSocket class.


> > Why not?

>
> It leaks credentials unnecessarily.


<http://www.hpi.de/>
Ah, good point! But this pattern (EAFP for web connections) is not really state of the art, is it? As mentioned, curl, for example, sends the authentication data in the very first request, which is a tool I would tend to *call* state of the art. And speed is another point, given the fact that internet connections in Squeak are really slow ...
Why do you call this behavior a leak? The application developer will not pass authentication data to the web client unless they expect the server to consume these data anyway. If you deem it necessary, we could turn off the pre-authentication as soon as the client was redirected to another server ...

> 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.

Alright, please see WebClient-Core-ct.128. But maybe we should consider to use prettyDiff for the mailing list notifications as a default? Just an idea.

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:55:39
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: WebClient-Core-ct.126.mcz

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201012/618aeae5/attachment.html>