<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Tobias,</p>
<p><br>
</p>
<p>okay, I see this authorization pattern now, so you mentioned two ways to work around the current limitations:</p>
<p>First, by GETting <a href="https://api.github.com/authorizations" class="x_OWAAutoLink" id="LPlnk147803">https://api.github.com/authorizations</a> before, or second, by passing the <span>Authorization header manually.</span></p>
<p><span>Is this correct?</span></p>
<p><span><br>
</span></p>
<p><span>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: <a href="https://github.com/Metacello/metacello/pull/534" class="x_OWAAutoLink" id="LPlnk682284">https://github.com/Metacello/metacello/pull/534</a></span></p>
<p>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.</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">> Why not?</span></p>
<div>> </div>
<div>> It leaks credentials unnecessarily.</div>
<div><br>
</div>
<p></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">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 ...</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">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 ...</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">> <span style="font-size:12pt">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.</span>
<div><br>
</div>
<div>Alright, please see <span>WebClient-Core-ct.128. But maybe we should consider to use prettyDiff for the mailing list notifications as a default? Just an idea.</span></div>
<div><span><br>
</span></div>
<div><span>Best,</span></div>
<div><span>Christoph</span></div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
<b>Gesendet:</b> Montag, 12. Oktober 2020 21:55:39<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: WebClient-Core-ct.126.mcz</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hey Christoph<br>
<br>
> On 12.10.2020, at 21:25, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> <br>
> Hi Tobias!<br>
> <br>
> 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.<br>
<br>
You're conflating authentication and authorization.<br>
(That said, I think the header name is a misnomer in HTTP…, but I might be wrong)<br>
<br>
<br>
> For example, the GitHub API will respond with a 404 error if you try to access the following URL without authorization:
<a href="https://api.github.com/repos/LinqLover/openHAB-configuration/zipball/master">
https://api.github.com/repos/LinqLover/openHAB-configuration/zipball/master</a><br>
> However, I sweat that this repository actually exists, and I will get a 202 OK response if I authenticate before!<br>
> 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.<br>
<br>
<br>
No its different.<br>
Look: if you go to<br>
<a href="https://api.github.com/">https://api.github.com/</a><br>
One of the json entries is:<br>
<br>
authorizations_url: "<a href="https://api.github.com/authorizations">https://api.github.com/authorizations</a>"<br>
<br>
If you go to <br>
<br>
"<a href="https://api.github.com/authorizations">https://api.github.com/authorizations</a>"<br>
<br>
You'll get the 401.<br>
<br>
>From then on, all HTTP Clients will continue with authorization headers.<br>
<br>
No preauth required.<br>
<br>
If I'm authenticated that way, I as krono will get the 404 on your url, but you as LinqLover will get 200.<br>
<br>
<br>
And yes, Github essentially says "F$#^#$ Standards":<br>
<br>
<a href="https://docs.github.com/en/free-pro-team@latest/rest/overview/other-authentication-methods">https://docs.github.com/en/free-pro-team@latest/rest/overview/other-authentication-methods</a><br>
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.<br>
<br>
And I hate it.<br>
They're trading privacy for security. That's a dick move.<br>
<br>
NB: For 2FA, you need the <a href="https://api.github.com/authorizations">https://api.github.com/authorizations</a> endpoint anyways:
<a href="https://docs.github.com/en/free-pro-team@latest/rest/overview/other-authentication-methods#working-with-two-factor-authentication">
https://docs.github.com/en/free-pro-team@latest/rest/overview/other-authentication-methods#working-with-two-factor-authentication</a><br>
<br>
So maybe, first going to "<a href="https://api.github.com/authorizations">https://api.github.com/authorizations</a>" is a good idea in the first place?
<br>
<br>
:D<br>
<br>
It's not your fault, I understand you just want to get things going.<br>
GitHub is a too big player and we have to scratch standards for that, sigh…<br>
<br>
<br>
> > I do not support preemtive authentication, especially in non-SSL circumstances.<br>
> <br>
> Why not?<br>
<br>
It leaks credentials unnecessarily.<br>
<br>
> However, I would not dislike a warning being raised every time you try to authenticate if the scheme is not https.<br>
<br>
WebClient is pretty lean for a HTTP client, I'd rather have it continue that way.<br>
<br>
That said, you can simply do<br>
<br>
WebClient <br>
httpGet: '<a href="https://api.github.com/repos/LinqLover/openHAB-configuration/zipball/master">https://api.github.com/repos/LinqLover/openHAB-configuration/zipball/master</a>'<br>
do: [:req | req headerAt: 'Authorization' put: 'WHATEVER-NECESSARY']<br>
<br>
And you have your pre-auth.<br>
<br>
> <br>
> > It is also hard to see the differences because you reformatted them method :/<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
<br>
Best regards<br>
-Tobias<br>
<br>
> <br>
> Best,<br>
> Christoph<br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
> Gesendet: Montag, 12. Oktober 2020 21:06:21<br>
> An: The general-purpose Squeak developers list<br>
> Betreff: Re: [squeak-dev] The Inbox: WebClient-Core-ct.126.mcz<br>
> <br>
> Hi<br>
> <br>
> > On 12.10.2020, at 20:47, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> > <br>
> > 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.<br>
> <br>
> <br>
> No, thats not what the link says:<br>
> <br>
> Q: "1. How to deal with unauthorized requests?<br>
> <br>
> I'm intending to respond to requests with the following codes:<br>
> <br>
> • Is the resource open and found? 200 OK<br>
> • Do you need to be authenticated to access the resources? 401 Unauthorized<br>
> • Don't you have access to a category of resources? 403 Forbidden<br>
> • 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.<br>
> • Doesn't the resource exist? 404 Not Found<br>
> <br>
> "<br>
> A: "How to deal with unauthorized requests?<br>
> <br>
> 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."<br>
> <br>
> <br>
> That means: "Do you need to be authenticated to access the resources? 401 Unauthorized"
<br>
> <br>
> I do not support preemtive authentication, especially in non-SSL circumstances.<br>
> <br>
> <br>
> =-=-=-=<br>
> <br>
> <br>
> It is also hard to see the differences because you reformatted them method :/<br>
> <br>
> Best regards<br>
> -Tobias<br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>