Just to bring things up to date, the suggestion by Anro almost worked.
I was able to trace through the unit and found the part which actually sent
the Header and watched it go line by line along with the basic auth.
>From there I realised that there was something wrong with the values and
simply Base64 encoded the token value so that the function actually I ended
up with was as follows:
procedure TForm1.SslHttpCli1BeforeHeaderSend(Sender: TObject;
const Method: String; Headers: TStrings);
begin
if Method = 'GET' then
Headers.Add( 'Authorization: Basic ' + EncodeStr(encBase64, sToken +
':' ));
end;
I spotted a function which gave me the idea to try Base64 encoding. Oddly
enough the sToken returned is already base64 encoded but re-encoding it
worked.
I've also found what I believe is the reason that basic authentication is
never passed to the server....
In the function PrepareBasicAuth, the main body of the function is never
executed because "if (FStatusCode = 401) and (FDoAuthor.Count > 0)" is
never true
It turns out that the API never returns a 'WWW-Authenticate' header so that
FDoAuthor.Add is never called, consequentially FDoAuthor.Count is always
zero.
I don't however see why it needs to wait for a 'WWW-Authenticate' header
when we could have already sent the Auth Header when doing the GET
Shouldnt the auth just be sent if the properties have been set?
Isn't that part of the idea behind Basic as opposed to Digest requires an
extra roundtrip to exchange the nonce value?
Any thoughts/feedback much appreciated.
Kind Regards, Wayne
On 18 February 2014 21:37, Wayne Phipps <waynephi...@gmail.com> wrote:
> OK, I've tried that now but it's unfortunately made no difference.
>
> Just for info, I've set two breakpoints. One on the function
> THttpCli.PrepareBasicAuth and the second on the procedure
> THttpCli.StartAuthBasic which I rightly or wrongly expected to be called.
>
> The breakpoint at StartBasicAuth never gets hit whilst the
> PrepareBasicAuth never makes it passed "if (FStatusCode = 401) and
> (FDoAuthor.Count > 0) and"
>
> I did notice the following comment in the class file which made me smile:
> { ServerAuth and ProxyAuth properties are still experimental. They are
> likely to change in the future. If you use them now, be prepared to update
> your code later }
>
> In the meanwhile, I'll continue to investigate.
>
> Kind Regards, Wayne
>
>
>
>
>
> On 18 February 2014 18:33, Wayne Phipps <waynephi...@gmail.com> wrote:
>
>> Not yet, I didn't spot that function but that sounds like a good plan.
>>
>> Thanks Arno, I'll give that a go.
>>
>> Kind Regards, Wayne
>> On 18 Feb 2014 18:26, "Arno Garrels" <arno.garr...@gmx.de> wrote:
>>
>>> On Tuesday, February 18, 2014 2:01 PM [GMT+1=CET],
>>> Wayne Phipps wrote:
>>>
>>> > Now we've come to implement the interface in Delphi, we've hit a
>>> > hurdle.
>>> >
>>> >
>>> >
>>> > The process should be as follows:
>>> >
>>> > 1) Use HTTP POST to pass username and password parameters to
>>> > login URL
>>> >
>>> > 2) A token string is returned if login was successful
>>> >
>>> > 3) The token is then used as Basic Authentication using HTTP GET
>>> > to retrieve JSON from different API URL
>>>
>>> Have you tried to add the basic authenticate header line manually at
>>> runtime, something like:
>>>
>>> procedure THttpTestForm.HttpCli1BeforeHeaderSend(Sender: TObject;
>>> const Method: string; Headers: TStrings);
>>> begin
>>> if Method = 'GET' then
>>> Headers.Add('Authorization: Basic ' + TokenString);
>>> end;
>>>
>>> --
>>> Arno
>>>
>>> --
>>> To unsubscribe or change your settings for TWSocket mailing list
>>> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
>>> Visit our website at http://www.overbyte.be
>>>
>>
>
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
