🚀 go-pugleaf

"Jyrki Saario" <user@domain.invalid> wrote in message 
news:48035008@newsgroups.borland.com...

> I try to connect to server what uses Digest authentication to
> download page under URL: http://192.168.0.10/rmt/index.shtml
>
> When I run my program, I will get exception HTTP/1.0 401 Unauthorized 
> access

What do you have the AuthRetries and MaxAuthRetries properties set to?

>    HTTP->Get("http://192.168.0.10/rmt/index.shtml", stream);
>    stream->Position = 0;
>    stream->SaveToFile(DirPathEdit->Text + "\Test.html");

If you use a TFileStream instead, you can avoid saving the file to memory 
first:

    TFileStreamStream *stream = new TFileStream(DirPathEdit->Text + 
"\Test.html", fmCreate);
    HTTP->Get("http://192.168.0.10/rmt/index.shtml", stream);

>    stream->Free();

Use the 'delete' operator instead of calling Free() directly:

    delete stream;

> in HTTPSelectAuthorization event, I can find this information
> from AuthInfo->Text:
<snip>

Are you getting an OnAuthorization event triggered at all?

> What is wrong, what do I need to do to get this work?

Did you verify with a packet sniffer that TIdHTTP is even attempting to 
login with the Digest credentials at all?

> Do I need to make MD5 of password my self?

No.


Gambit 

Remy Lebeau (TeamB) kirjoitti:
>> I try to connect to server what uses Digest authentication to
>> download page under URL: http://192.168.0.10/rmt/index.shtml
>>
>> When I run my program, I will get exception HTTP/1.0 401 Unauthorized 
>> access
> 
> What do you have the AuthRetries and MaxAuthRetries properties set to?

AuthRetries can not be set, but when I read value it's 0. MaxAuthRetries 
is set to 3.

>>    HTTP->Get("http://192.168.0.10/rmt/index.shtml", stream);
>>    stream->Position = 0;
>>    stream->SaveToFile(DirPathEdit->Text + "\Test.html");
> 
> If you use a TFileStream instead, you can avoid saving the file to memory 
> first:
> 
>     TFileStreamStream *stream = new TFileStream(DirPathEdit->Text + 
> "\Test.html", fmCreate);
>     HTTP->Get("http://192.168.0.10/rmt/index.shtml", stream);

You are absolutely right. I will change it...

>>    stream->Free();
> 
> Use the 'delete' operator instead of calling Free() directly:
> 
>     delete stream;
OK.

>> in HTTPSelectAuthorization event, I can find this information
>> from AuthInfo->Text:
> <snip>
> 
> Are you getting an OnAuthorization event triggered at all?

Yes. It's triggered. This information is taken from event trigger:
AuthInfo->Text:
Digest realm="WebPage Configuration", 
nonce="MDAwMDAwMDA2MDo1MzQ6MTkyLjE2OC4yMzAuMjUz", algorithm=MD5, 
domain="Agent: Mozilla/3.0 (compatible; Indy Library)", qop="auth"

And AuthenticationClass->ClassName() shows:
TIdDigestAuthentication

> Did you verify with a packet sniffer that TIdHTTP is even attempting to 
> login with the Digest credentials at all?

Wireshark is now downloaded, I will take a deeper look...



J.S

"Jyrki Saario" <no_mail@invalid.inv> wrote in message 
news:480396b8$1@newsgroups.borland.com...

>> Are you getting an OnAuthorization event triggered at all?
>
> Yes. It's triggered. This information is taken from event trigger:
> AuthInfo->Text:
> Digest realm="WebPage Configuration", 
> nonce="MDAwMDAwMDA2MDo1MzQ6MTkyLjE2OC4yMzAuMjUz", algorithm=MD5, 
> domain="Agent: Mozilla/3.0 (compatible; Indy Library)", qop="auth"
>
> And AuthenticationClass->ClassName() shows:
> TIdDigestAuthentication

I was referring to the *OnAuthorization* event, not the 
*OnSelectAuthorization* event.  They are separate.  If *OnAuthorization* is 
begin triggered, then the server is rejecting the Digest credentials, or 
they are not being transmitted to begin with.


Gambit 

Remy Lebeau (TeamB) kirjoitti:
> I was referring to the *OnAuthorization* event, not the 
> *OnSelectAuthorization* event.  They are separate.  If *OnAuthorization* is 
> begin triggered, then the server is rejecting the Digest credentials, or 
> they are not being transmitted to begin with.

Sorry my oversight. OnAuthorization is not triggered.

J.S

"Jyrki Saario" <no_mail@invalid.inv> wrote in message 
news:4803ac9f$1@newsgroups.borland.com...

> Sorry my oversight. OnAuthorization is not triggered.

Then TIdDigestAuthentication is probably not sending any credentials at all. 
A pacekt sniffer will verify that one way or the other.


Gambit 

Remy Lebeau (TeamB) kirjoitti:
> Then TIdDigestAuthentication is probably not sending any credentials at all. 
> A pacekt sniffer will verify that one way or the other.

Started Wireshark and seems that my program sends credentials to server. 
Next package after my programs GET message (shipped with digest 
authentication stuff) is "HTTP/1.0 401 Unathorized access" error from 
server.
Only big difference what I can find compared to browser is that Indy is 
sending cnonce as well and uri value is empty.

J.S

"Jyrki Saario" <no_mail@invalid.inv> wrote in message 
news:4803c9ba$1@newsgroups.borland.com...

> Started Wireshark and seems that my program sends credentials to server.

Can you show the actual packet data that Wireshark captures?


Gambit 

Jyrki Saario wrote:
> Here is more details of my program:
> One button with code:
>    TMemoryStream *stream;
>    stream = new TMemoryStream( );
> 
> J.S

Why you don't use Delphi? What you code is not C++.

TMemoryStream *stream = new TMemoryStream;

;)

Markus

Remy Lebeau (TeamB) wrote:
> Can you show the actual packet data that Wireshark captures?

Here is more details from HTTP packages:
1. My program sends GET message
2. Server answers with 401
3. My programs sends this GET message with authentication information:

GET /Remote/index.shtml HTTP/1.1\r\n
Host: 192.168.0.13\r\n
Accept: text/html, */*\r\n
Accept-Encoding: identity\r\n
User-Agent: Mozilla/3.0 (compatible; Indy Library)\r\n
[truncated] Authorization: Digest username="username", realm="WebPage 
Configuration", nonce="MDAwMDAwMDExNDo0MjY6MDEwLjA0Ni4wMDguMDEx", 
algorithm="MD5", uri="", qop="auth", nc=00000001, 
cnonce="e1a8e5c838d1878ebb7dfe599d00940e", response="9f43f1


4. Server answers:
HTTP/1.0 401  Unauthorized access\r\n
WWW-Authenticate: Digest realm="WebPage Configuration", 
nonce="MDAwMDAwMDExNTo1NzY6MDEwLjA0Ni4wMDguMDEx", algorithm=MD5, 
domain="rization:", qop="auth"\r\n
Server: GAH-Web\r\n
Content-Type: text/html\r\n
Content-Length: 107

this same procedure will be done two times more.
Please let me know if you need more info from lower level.

J.S

"Jyrki Saario" <user@domain.invalid> wrote in message 
news:48047653@newsgroups.borland.com...

> Here is more details from HTTP packages:

When you retreive the same page using a web browser, what does the 
authorization data look like?  How does it differ from what Indy sends?


Gambit 

Remy Lebeau (TeamB) wrote:

>>    stream->SaveToFile(DirPathEdit->Text + "\Test.html");
>
>    TFileStreamStream *stream = new TFileStream(
>	DirPathEdit->Text + "\Test.html", fmCreate);

Tch...
	DirPathEdit->Text + "\\Test.html", fmCreate);

Remy Lebeau (TeamB) wrote:
> When you retreive the same page using a web browser, what does the 
> authorization data look like?  How does it differ from what Indy sends?

Hope this helps to find out:

Browser (this succeed) :
GET /rmt/index.shtml HTTP/1.1
Host: 192.168.0.13
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) 
Gecko/20080311 Firefox/2.0.0.13
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en,sv;q=0.8,fi;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://192.168.0.13/
Authorization: Digest username="user", realm="Web Configuration", 
nonce="MDAwMDAwMDEyMDo1MTc6MTkyLjE2OC4yMzEuMTAz", 
uri="/rmt/index.shtml", algorithm=MD5, 
response="0f40310b510b996b374d36c431acc984", qop=auth, nc=00000001, 
cnonce="d4982618229ed456"

My program (this failed):
GET /rmt/index.shtml HTTP/1.1
Host: 192.168.0.13
Accept: text/html, */*
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
Authorization: Digest username="user", realm="Web Configuration", 
nonce="MDAwMDAwMDEyMToyOTE6MTkyLjE2OC4yMzEuMTAz", algorithm="MD5", 
uri="", qop="auth", nc=00000001, 
cnonce="c4fce4dfd34665f8b1a9d3ba840384f4", 
response="8877c6af46a883b6d05cb15792ad442f"

Any ideas?

J.S

"Jyrki Saario" <user@domain.invalid> wrote in message 
news:4804eef3$1@newsgroups.borland.com...

> Any ideas?

As you can see, Indy is not filling in the "uri" portion of the 
authorization.  That is a known bug that has not been fixed yet.  That in 
turn is throwing off the MD5 calculations.


Gambit 

Remy Lebeau (TeamB) wrote:
> As you can see, Indy is not filling in the "uri" portion of the 
> authorization.  That is a known bug that has not been fixed yet.  That in 
> turn is throwing off the MD5 calculations.


Thanks Remy, that I was thinking about also, but wasn't 100% sure.
I have not looked into code yet, but what do you think, is there any 
easy solution to set that uri explicitly? Cause in my case, it will 
always remain the same. That one page will include some special 
information what I need to receive, but there is absolutely nothing else 
what I need (this far). If there is any ideas, it's worth to try out.

J.S

"Jyrki Saario" <user@domain.invalid> wrote in message 
news:480504a7$1@newsgroups.borland.com...

> I have not looked into code yet, but what do you think,
> is there any easy solution to set that uri explicitly?

I suppose as a workaround that you can use the OnSelectAuthorization and/or 
OnAuthorization events to check for TIdDigestAuthentication being used, and 
if detected then fill in its Uri property manually.   A better solution is 
to fix TIdDigestAuthentication to fill in its own Uri property from the HTTP 
server's 401 reply data correctly.


Gambit 

Remy Lebeau (TeamB) wrote:
> I suppose as a workaround that you can use the OnSelectAuthorization and/or 
> OnAuthorization events to check for TIdDigestAuthentication being used, and 
> if detected then fill in its Uri property manually.   

OK. Any ideas how to get access to TIdDigestAuthentication instance from 
SelectAuthorization event (to set the uri)? Seems that OnAuthorization 
event does not trigger at all, any explanations why?

J.S

"Jyrki Saario" <user@domain.invalid> wrote in message 
news:48052dfb$1@newsgroups.borland.com...

> OK. Any ideas how to get access to TIdDigestAuthentication
> instance from SelectAuthorization event (to set the uri)?

Sorry, my mistake.  You cannot do it from that event.  Only from the 
OnAuthorization event.  OnSelectAuthorization is fired when TIdHTTP needs 
you to decide which TIdAuthentication class it should use, and then it 
creates an instance after the OnSelectAuthorization event handler exits.

If you know that Digest will always be used, you can assign the 
TIdHTTP.Request.Authentication property yourself before calling Get().  Then 
you will have access to the TIdDigestAuthentication object (since you have 
to provide one yourself).

> Seems that OnAuthorization event does not trigger
> at all, any explanations why?

Apparently TIdDigestAuthentication needs some work.  It does not seem to be 
implemented very well.

Try setting the TIdHTTP.Request.Username property to an empty string before 
calling Get().  That should force the OnAuthorization event to fire.


Gambit