Hi

> On 12.10.2020, at 23:42, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> 
> 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?

Yes. However, the second one is the one GitHub "recommends"


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

There is no such thing as simplicity when a REST-Based resource-provider supports both authenticated and unauthenticated access.
If you cannot know beforehand, no single-request stuff is gonna help. No dice.
 

> 
> > > Why not?
> > 
> > It leaks credentials unnecessarily.
> 
> 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.

No thats wrong. Curl will only send auth data if you provide it. 

Doing "curl -u user:pw" is the same as using WebClient httpGet:do: and adding the Authorization header manually


The sequence is split manually:
```
$ curl https://api.github.com/repos/krono/debug/zipball/master
{
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest/reference/repos#download-a-repository-archive"
}
# Well, I'm left to guess. Maybe exists, maybe not.
$ curl -u krono https://api.github.com/repos/krono/debug/zipball/master

```
(In this case, I can't even show what's going on as I use 2FA, which makes single-request REST to _never_ work on private repos.)

The point is, you instruct Curl to _provide credentials unconditionally_.
The "heavy lifting" of finding out when to do that is not done by curl but by users of curl.

Look:

```
$ curl http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/xpaware/
$ 
# Well, no response?
$ curl  -v http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/xpaware/
*   Trying 2001:638:807:204::8d59:e178...
* TCP_NODELAY set
* Connected to www.hpi.uni-potsdam.de (2001:638:807:204::8d59:e178) port 80 (#0)
> GET /hirschfeld/squeaksource/xpaware/ HTTP/1.1
> Host: www.hpi.uni-potsdam.de
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401
< Date: Tue, 13 Oct 2020 07:43:04 GMT
< Server: nginx/1.14.2
< Content-Length: 0
< WWW-Authenticate: Basic realm="SwaSource - XP aware"
<
* Connection #0 to host www.hpi.uni-potsdam.de left intact
```

Thats the 401 we're looking for. We have found that the resource needs authentication.

Sidenote: Curl can do the roundtrip (man curl, search anyauth):

```
$ curl -u topa --anyauth -v http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/xpaware/
Enter host password for user 'topa':
*   Trying 2001:638:807:204::8d59:e178...
* TCP_NODELAY set
* Connected to www.hpi.uni-potsdam.de (2001:638:807:204::8d59:e178) port 80 (#0)
> GET /hirschfeld/squeaksource/xpaware/ HTTP/1.1
> Host: www.hpi.uni-potsdam.de
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401
< Date: Tue, 13 Oct 2020 07:46:05 GMT
< Server: nginx/1.14.2
< Content-Length: 0
< WWW-Authenticate: Basic realm="SwaSource - XP aware"
<
* Connection #0 to host www.hpi.uni-potsdam.de left intact
* Issue another request to this URL: 'http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/xpaware/'
* Found bundle for host www.hpi.uni-potsdam.de: 0x7fb8c8c0b1b0 [can pipeline]
* Re-using existing connection! (#0) with host www.hpi.uni-potsdam.de
* Connected to www.hpi.uni-potsdam.de (2001:638:807:204::8d59:e178) port 80 (#0)
* Server auth using Basic with user 'topa'
> GET /hirschfeld/squeaksource/xpaware/ HTTP/1.1
> Host: www.hpi.uni-potsdam.de
> Authorization: Basic *******************
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200
< Date: Tue, 13 Oct 2020 07:46:05 GMT
< Server: nginx/1.14.2
< Content-Type: text/html
< Content-Length: 15131
< Vary: Accept-Encoding
```

And in this case it does _not_ send auth in the first request but only in the second.

Sidenote2: If the first request comes back 200, no second one is issued, no credentials leak:

```
$ curl -u topa --anyauth -v http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/xpforums/
Enter host password for user 'topa':
*   Trying 2001:638:807:204::8d59:e178...
* TCP_NODELAY set
* Connected to www.hpi.uni-potsdam.de (2001:638:807:204::8d59:e178) port 80 (#0)
> GET /hirschfeld/squeaksource/xpforums/ HTTP/1.1
> Host: www.hpi.uni-potsdam.de
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200
< Date: Tue, 13 Oct 2020 07:46:56 GMT
< Server: nginx/1.14.2
< Content-Type: text/html
< Content-Length: 75860
< Vary: Accept-Encoding
```





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

So you always know beforehand which resources need authentication?
Neat, I dont :D

> If you deem it necessary, we could turn off the pre-authentication as soon as the client was redirected to another server ...

What happens here is that we're bending over backwards because github decided to be a bad player.

I mean, on most sited you visit in browsers, no auth data is sent _unless_ you are asked to (redirect to a login) or you _explicitely_ click on a login link.

If you want preemtive auth, do it with WebClient httpGet:do:.



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

I personally find prettydiffs useless, but that's just me.

Best regards
	-Tobias