HTTP + Proxy - Anyone tried it in Delphi?
Alan Garny
proxy server. I don't seem to get it to work (keep getting that annoying
"HTTP/1.1 407 Proxy Authentication Required"), despite what I think is a
valid code (see my other message). This would therefore confirm what I have
seen in other messages, i.e. there is something broken with TIdHTTP using a
proxy server.
Now, the question is to know whether someone:
1) has actually managed to use TIdHTTP with a proxy and if so, what did you
have to do? I am happy to admit I made a mistake, but for that I need
someone who shows me I have made one... :)
2) has given up on using TIdHTTP with a proxy and, if so, what other
solution s/he has decided to use instead, keeping in mind I need a free
solution (my project is open source).
Cheers, Alan.
Alan Garny
news:Xns946EDDD...@207.105.83.66...
> Alan Garny wrote:
> > Now, the question is to know whether someone:
> "Integrated" (aka NTLM) authentication? Some other method?
I don't know and I am not sure it should matter. I mean that in the worst
case, the user should be allowed to specify which method is to be used, no?
Ideally, it would be determined automatically. Either way, I don't know how
to do that... so if you know, I would be more than happy to learn from
you...
Alan.
![Ben Hochstrasser [FF]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Ben Hochstrasser [FF]
> Now, the question is to know whether someone:
What style of authentication does your proxy expect? Plain text?
"Integrated" (aka NTLM) authentication? Some other method?
--
Ben
Alan Garny
news:4003164c$1...@newsgroups.borland.com...
> Please try Clever Internet Suite v 3.3 at
> http://www.clevercomponents.com/downloads/inetsuite.asp - it perfectly
> compatible with proxy (including NTLM proxy authentification)
Too bad, I said a free solution (and with source code, in fact)... and there
is no way around that...
Alan.
CleverComponents Team
Please try Clever Internet Suite v 3.3 at
http://www.clevercomponents.com/downloads/inetsuite.asp - it perfectly
compatible with proxy (including NTLM proxy authentification)
Other Clever Internet Suite links:
- Home Page http://clevercomponents.com/products/inetsuite/suite.asp
- Downloads http://clevercomponents.com/downloads/inetsuite.asp
- Compiled Demos http://clevercomponents.com/downloads/inetsuite.asp
- Online Demos http://clevercomponents.com/products/inetsuite/demos.asp
- History http://clevercomponents.com/products/inetsuite/suitehistory.asp
- FAQ http://clevercomponents.com/products/inetsuite/inetsuitefaqs.asp
With Best Regards,
Clever Components Team
http://www.clevercomponents.com
"Alan Garny" <som...@somewhere.com> wrote in message
news:400307a5$1...@newsgroups.borland.com...
Remy Lebeau (TeamB)
> I don't know and I am not sure it should matter.
Yes, it makes a BIG difference. Different authentication schemes encode the
login info that is sent to the proxy in VERY different ways. You must know
the exact authentication scheme that the proxy is actually using so that you
can then configure TIdHTTP to login to the proxy in the correct manner.
> I mean that in the worst case, the user should be allowed to specify
> which method is to be used, no?
Yes, but then you have to actually set up the TIdHTTP accordingly.
> Ideally, it would be determined automatically.
For TIdHTTP to do that, you need to add the various TIdAuthentication...
units (TIdAuthenticationDigest, TIdAuthenticationNTLM,
TIdAuthenticationSSPI) to your programs' 'uses' clause. Even then, that is
not a guarantee that everything will be handled automatically 100% for you.
You will probably still have to interact with the values a little bit.
Gambit
Alan Garny
news:40031d6c$1...@newsgroups.borland.com...
> "Alan Garny" <som...@somewhere.com> wrote in message
> news:4003...@newsgroups.borland.com...
> > I don't know and I am not sure it should matter.
> Yes, it makes a BIG difference. Different authentication schemes encode
the
> login info that is sent to the proxy in VERY different ways. You must
know
> the exact authentication scheme that the proxy is actually using so that
you
> can then configure TIdHTTP to login to the proxy in the correct manner.
That, I agree with.
> > I mean that in the worst case, the user should be allowed to specify
> > which method is to be used, no?
> Yes, but then you have to actually set up the TIdHTTP accordingly.
Yes, how do we do that then?
> > Ideally, it would be determined automatically.
> For TIdHTTP to do that, you need to add the various TIdAuthentication...
> units (TIdAuthenticationDigest, TIdAuthenticationNTLM,
> TIdAuthenticationSSPI) to your programs' 'uses' clause. Even then, that
is
> not a guarantee that everything will be handled automatically 100% for
you.
> You will probably still have to interact with the values a little bit.
Adding the units is ok, but what next? Surely, to add them alone won't do
the trick, right?
Man, what a mess! :( Sorry, but I am really getting disappointed with that
TIdHTTP component. There are programs that only require the information I
ask my user to go through a proxy, so why can't I do the same? Surely, it
must be possible! No??
Alan.
PS: it sounds to me like nobody has ever managed to use TIdHTTP with a proxy
server. If I am wrong, please show me some code! Until that proxy thing, I
thought the Indy components were great, but now that one of my users is
behind a proxy and cannot access my web site, I think they s*ck big time!
Yes, that's the end of the day, so I guess I am getting a bit tired and easy
to upset...
Ben Hochstrasser [FF]
> Too bad, I said a free solution (and with source code, in fact)... and
> there is no way around that...
Synapse. Reportedly (did it myself) works with proxy.
Do you have to log on to your proxy with MSIE? No? Then you're using SSPI
or NTLM, else you probably use Basic (aka clear text) authentication.
--
Ben
Remy Lebeau (TeamB)
> Yes, how do we do that then?
Use the ProxyParams.Authentication property. You set it to the class
instance of the particular authentication scheme to use, and then fill in
that instance accordingly.
> Adding the units is ok, but what next? Surely, to add them alone won't do
> the trick, right?
Yes, it would. Each unit has a RegisterAuthenticationMethod() call in its
Initialization section. TIdHTTP can then look at the server's initial
connection response to see what kind of authentication it is expecting, then
it can look through the currently registered TIdAuthentication classes for a
match, and if found then use it.
> Man, what a mess! :( Sorry, but I am really getting disappointed with that
> TIdHTTP component.
This has nothing to do with TIdHTTP specifically. You need to understand
how HTTP authentication works in general to begin with, then you will begin
to understand why TIdHTTP is designed the way it is. Keep in mind that
everything in Indy is designed with scalability and flexibility in mind, so
things are generalized alot.
> There are programs that only require the information I ask my user
> to go through a proxy
Such programs are most likely setup to either 1) only work with specific
types of authentications, or 2) they are written to work with ALL
authentication types and then automatically pick which ones to use sothat
the user never knows what is going on. Indy is the latter, except that
everything is modularized and those modules are not all enabled by default,
it would bloat the component too much for everyone else who just need basic
HTTP services. If you want advanced features, like proxying, you simply
plugin in the extra pieces that are needed, configure them, and off you go.
> PS: it sounds to me like nobody has ever managed to use TIdHTTP
> with a proxy server.
I doubt that very much. TIdHTTP has had proxy support for a long time. If
nobody were having any luck with it at all, there would have been a lot more
bug reports, and a lot more attention focused on it.
Gambit
Alan Garny
> "Alan Garny" <som...@somewhere.com> wrote in message
> news:4003214f$3...@newsgroups.borland.com...
do
> > the trick, right?
> Yes, it would. Each unit has a RegisterAuthenticationMethod() call in its
> Initialization section. TIdHTTP can then look at the server's initial
> connection response to see what kind of authentication it is expecting,
then
> it can look through the currently registered TIdAuthentication classes for
a
> match, and if found then use it.
I just had a look at them and indeed... except that the Digest
authentication method is untested (dixit a comment by Doychin Bondzhev in
the code) and that the call to "RegisterAuthenticationMethod" in the
initialization section is commented out... so, that leaves me the basic and
NTLM authentication to play with...
> > Man, what a mess! :( Sorry, but I am really getting disappointed with
that
> > TIdHTTP component.
> This has nothing to do with TIdHTTP specifically. You need to understand
> how HTTP authentication works in general to begin with, then you will
begin
> to understand why TIdHTTP is designed the way it is. Keep in mind that
> everything in Indy is designed with scalability and flexibility in mind,
so
> things are generalized alot.
Yes, I start seeing that... still the documentation is not very helpful...
not to mention that in my copy of D7, there is no Indy demo. Fair enough
there is a file that points to their web site, so I went there... but
nothing... unless I didn't look in the right place...
> > There are programs that only require the information I ask my user
> > to go through a proxy
> Such programs are most likely setup to either 1) only work with specific
> types of authentications, or 2) they are written to work with ALL
> authentication types and then automatically pick which ones to use sothat
> the user never knows what is going on. Indy is the latter, except that
> everything is modularized and those modules are not all enabled by
default,
or tested for that matter... <g>
> it would bloat the component too much for everyone else who just need
basic
> HTTP services. If you want advanced features, like proxying, you simply
> plugin in the extra pieces that are needed, configure them, and off you
go.
That's fair enough. As it happens, I like that kind of approach. It's just
not very clear at first glance.
> > PS: it sounds to me like nobody has ever managed to use TIdHTTP
> > with a proxy server.
> I doubt that very much. TIdHTTP has had proxy support for a long time.
If
> nobody were having any luck with it at all, there would have been a lot
more
> bug reports, and a lot more attention focused on it.
Well, as I said I did spend quite a bit of time, before posting here,
looking for a solution in the archives, but was more than unsuccessful.
Again, I am more than happy to be proven wrong... but so far, everything
seems to prove me right... unfortunately...
This said, I will, whenever I have a bit of time (this whole TIdHTTP+Proxy
issue has already taken far too much of my limited free time) have a proper
look at that authentication property, even thought the digest method doesn't
seem reliable as it stands (for it hasn't been tested).
Alan.
Remy Lebeau (TeamB)
> I just had a look at them and indeed... except that the Digest
> authentication method is untested (dixit a comment by Doychin
> Bondzhev in the code) and that the call to
> "RegisterAuthenticationMethod" in the initialization section is
> commented out... so, that leaves me the basic and NTLM
> authentication to play with...
There was a discussion on that not too long ago. Try looking at past
messages.
> Yes, I start seeing that... still the documentation is not very helpful...
Complain to the documentation people about that. They have thier own group.
And if you are really interested in getting better docs, you could always
join the group yourself and contribute to them.
Gambit
Alan Garny
>
> "Alan Garny" <som...@somewhere.com> wrote in message
> news:4003...@newsgroups.borland.com...
>
> > I just had a look at them and indeed... except that the Digest
> > authentication method is untested (dixit a comment by Doychin
> > Bondzhev in the code) and that the call to
> > "RegisterAuthenticationMethod" in the initialization section is
> > commented out... so, that leaves me the basic and NTLM
> > authentication to play with...
> There was a discussion on that not too long ago. Try looking at past
> messages.
Will do.
> > Yes, I start seeing that... still the documentation is not very
helpful...
> Complain to the documentation people about that. They have thier own
group.
> And if you are really interested in getting better docs, you could always
> join the group yourself and contribute to them.
Well, I am sorry, but I am already working on my own open source project
during my free time, so that doesn't leave me much free time (not to say
none at all). Not to mention that having the Indy components shipped with
D7, I would have expected some kind of support, but I guess I was wrong...
maybe I shouldn't be too surprised coming from Borland (due to their
legendary level of documentation - sarcasm).
Anyway, I have managed to get the proxy server details (basic
authentication) and authentication settings from my user. I should be able
to properly trace the problem from there...
Alan.
Remy Lebeau (TeamB)
> Not to mention that having the Indy components shipped with D7,
> I would have expected some kind of support, but I guess I was
> wrong... maybe I shouldn't be too surprised coming from Borland
> (due to their legendary level of documentation - sarcasm).
Borland has nothing to do with Indy. Indy's developers provide their own
support for Indy, Borland does not do that for them. Any issues you have
with Indy need to be directed to Indy's people directly, not Borland's.
Some of them frequent this group, and several frequent Indy's own newsgroups
at news.atozedsoftware.com.
Gambit
Alan Garny
I understand that Borland has nothing to do with Indy, yet I wish they were
a bit more constraining when components are to be added to the whole Delphi
package. I mean that, surely, I am not the only one to use all those
non-Borland tools that are shipped with D7. So, in that respect, I would
hope not to have to get in touch with every single one group/company that
developed those tools, should they be broken, etc. not to mention that some
of those groups/companies may go out of business.
Ok, enough criticism... :))
Thanks for the newsgroup address. I will give it a try.
Alan.
Alan Garny
> Alan Garny wrote:
> > Too bad, I said a free solution (and with source code, in fact)... and
> > there is no way around that...
> Synapse. Reportedly (did it myself) works with proxy.
Just out of interest, I gave it a try and it seems to be working fine, so at
this stage I will assume I have done something wrong with TIdHTTP...
This said, there doesn't appear to be a way to set pragma options. In other
words, there doesn't seem to be a way to specify that the document should be
retrieved from the web site and not the cache (i.e. "no-cache" option).
I have, however, hard coded it and it works nicely with it. So, overall, to
add "Pragma: no-cache" to the header does the trick. Not to mention that
authentication works fine.
I will, nonetheless, go back to TIdHTTP, as I would very much like to
understand what is going with that component... but at least, I now seem to
have a working solution (at least for basic authentication).
Alan.
Chad Z. Hower aka Kudzu
@newsgroups.borland.com:
> I understand that Borland has nothing to do with Indy, yet I wish they were
> a bit more constraining when components are to be added to the whole Delphi
> package. I mean that, surely, I am not the only one to use all those
Youve missed the entire point.
Borland only provides peer support on these NGs for their own products -
which is the same that is provided for Indy.
For priority support for Delphi, you have to pay Borland.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
Need extra help with an Indy problem?
http://www.atozed.com/indy/experts/support.html
ELKNews - Get your free copy at http://www.atozedsoftware.com
Alan Garny
news:Xns946F563...@127.0.0.1...
> "Alan Garny" <som...@somewhere.com> wrote in news:4003c000$1
> @newsgroups.borland.com:
> > I understand that Borland has nothing to do with Indy, yet I wish they
were
> > a bit more constraining when components are to be added to the whole
Delphi
> > package. I mean that, surely, I am not the only one to use all those
>
> Youve missed the entire point.
>
> Borland only provides peer support on these NGs for their own products -
> which is the same that is provided for Indy.
>
> For priority support for Delphi, you have to pay Borland.
Maybe you misunderstood me, I don't know, but what I was referring to is the
lack of examples for the Indy components. As I said, I went to the "your"
web site and couldn't find them, though in my D7 distribution, there is a
file in the demo folder that says that I would be able to find some there.
Maybe I didn't look in the right place?
Don't get me wrong, I greatly appreciate the work that you and others have
put in the Indy components. I just wish that there had been examples as how
to use them in different situations. You will have to agree that your
library of components is huge and can therefore be quite intimidating for
someone who only wants to use tiny bits of it.
Anyway, I have finally managed to get things to work the way I want and will
post a message about "my" findings, as well as some code snippets for those
who would be willing to do the same.
Alan.
Grahame Grieve
> Ok, I have been battling for quite some time for using TIdHTTP from
> behind a proxy server. I don't seem to get it to work (keep getting
> that annoying "HTTP/1.1 407 Proxy Authentication Required"), despite
> what I think is a valid code (see my other message). This would
> therefore confirm what I have seen in other messages, i.e. there is
> something broken with TIdHTTP using a proxy server.
well, it works for me, and I've posted my code to this newgroups
several times.
I'm not sure what you're trying to acheive though. If you're
rolling an app out to lot's of users, it's nicer to use wininet,
so that you just pick up the users proxy settings etc without
trying. Of course, you lose a lot of control doing this
Grahame
// creating the idhttp
Result := TIdHTTP.Create(NIL);
Result.HandleRedirects := True;
Result.Request.Username := FUsername;
Result.Request.Password := FPassword;
Result.OnSelectAuthorization := SelAuth;
Result.OnAuthorization := Auth;
// code for events
procedure class.Auth(Sender: TObject; Authentication:
TIdAuthentication; var VHandled: Boolean);
begin
VHandled := False;
end;
procedure TIdHTTPServerContext.SelAuth(ASender: TObject; var
VAuthenticationClass: TIdAuthenticationClass; AAuthInfo: TIdHeaderList);
begin
VAuthenticationClass := FAuthClass;
end;
// where FAuthClass is of type TIdAuthenticationClass
// you have to know what this is and set it correctly
// for NTLM I Use TIdSSPINTLMAuthentication from IdAuthenticationSSPI
Ian Groves
gave up trying.
Ian
"Alan Garny" <som...@somewhere.com> wrote in message
news:400307a5$1...@newsgroups.borland.com...
Alan Garny
news:40044424$1...@newsgroups.borland.com...
> Alan Garny wrote:
>
> > Ok, I have been battling for quite some time for using TIdHTTP from
> > behind a proxy server. I don't seem to get it to work (keep getting
> > that annoying "HTTP/1.1 407 Proxy Authentication Required"), despite
> > what I think is a valid code (see my other message). This would
> > therefore confirm what I have seen in other messages, i.e. there is
> > something broken with TIdHTTP using a proxy server.
>
> well, it works for me, and I've posted my code to this newgroups
> several times.
Argh! You might have saved me a lot of time yesterday, had you posted your
message back then... Not to mention that Remy Lebeau would have had to deal
with my ranting... :)
Oh well, now I have a working solution for a basic authentication
mechanism...
Ok, not quite what I have done (see my message entitled "To Remy Lebeau - Re
IdHTTP + proxy").
From the help file, I shouldn't need to set "HandleRedirects" to "True",
neither should you, since you don't seem to handle the "OnRedirect" event or
did I miss something?
Also, how do you decide what class "FAuthClass" should be an instance of?
Maybe from "AAuthInfo"?
Otherwise, just for the sake of it, I tried your solution (though without
setting "Result.Request.Username" and "Result.Request.Password"), but
couldn't have "OnSelectAuthorization" and "OnAuthorization" triggered...
Alan.
Remy Lebeau (TeamB)
> From the help file, I shouldn't need to set "HandleRedirects" to "True",
> neither should you, since you don't seem to handle the "OnRedirect"
> event or did I miss something?
The OnRedirect event is optional, it is not required in order for TIdHTTP to
handle redirects. Its main purpose is if you want to be able to update your
own resources with the new URL. For example, say you read a URL from a file
or database, and then perform the request. If the server reports that the
URL has moved, you can use the OnRedirect event to update your file/database
accordingly.
> Also, how do you decide what class "FAuthClass" should be an instance of?
The proxy sends back a "WWW-Authenticate" header value specifying the
required scheme to use. You can look at that value and then choose the
appropriate class.
> Maybe from "AAuthInfo"?
Yes.
Gambit
Alan Garny
> "Alan Garny" <som...@somewhere.com> wrote in message
> news:4004...@newsgroups.borland.com...
> > From the help file, I shouldn't need to set "HandleRedirects" to "True",
> > neither should you, since you don't seem to handle the "OnRedirect"
> > event or did I miss something?
> The OnRedirect event is optional, it is not required in order for TIdHTTP
to
> handle redirects. Its main purpose is if you want to be able to update
your
> own resources with the new URL. For example, say you read a URL from a
file
> or database, and then perform the request. If the server reports that the
> URL has moved, you can use the OnRedirect event to update your
file/database
> accordingly.
Nice.
> > Also, how do you decide what class "FAuthClass" should be an instance
of?
> The proxy sends back a "WWW-Authenticate" header value specifying the
> required scheme to use. You can look at that value and then choose the
> appropriate class.
>
> > Maybe from "AAuthInfo"?
> Yes.
Do you have any idea as why, using Grahame's code, those events don't get
triggered?
Otherwise, that would sound like the solution to adopt if I want to be able
to handle other authentication mechanisms besides the basic one...
Alan.
Remy Lebeau (TeamB)
> Do you have any idea as why, using Grahame's code,
> those events don't get triggered?
Because the code he posted is not dealing with the proxy at all. The
OnSelectAuthorization and OnAuthorization are triggered when the destination
HTTP server is asking for authorization, such as when accessing a
password-protected section of the website. For the proxy, you need to use
the OnSelectProxyAuthorization and OnProxyAuthorization events instead.
Gambit
Alan Garny
Argh! Sorry, I did use the right events in the first place, but they didn't
get triggered... and the reason was silly: I had left the
"BasicAuthentication" property set to "True"... my mistake... so to set to
"False" does raise "OnSelectProxyAuthorization", but not
"OnProxyAuthorization" since I had my proxy username/password set. So, if
don't set them, then "OnProxyAuthorization" will also be triggered.
Basically, it all make sense... now... :)
Alan.
Remy Lebeau (TeamB)
> so to set to "False" does raise "OnSelectProxyAuthorization", but
> not "OnProxyAuthorization" since I had my proxy username/password
> set. So, if don't set them, then "OnProxyAuthorization" will also be
triggered.
Not necessarily. OnProxyAuthorization is triggered whenever the server
requires valid login info. If you supply it upfront, and the information is
accurate, then there's no reason for the server to ask for it. However,
even if you do supply the username and password upfront, you might still get
the OnProxyAuthorization event if the values are wrong and the server needs
to ask for accurate values again.
Gambit
Alan Garny
Ok, I guess I should have said that my proxy username/password were set and
accurate, hence I didn't get the "OnProxyAuthorization" event triggered.
Otherwise, I agree, should the proxy username/password not be accurate, I
would expect "OnProxyAuthorization" to be triggered. Makes sense indeed.
Alan.
Alan Garny
news:40044424$1...@newsgroups.borland.com...
> // you have to know what this is and set it correctly
> // for NTLM I Use TIdSSPINTLMAuthentication from IdAuthenticationSSPI
By the way, why do you prefer TIdSSPINTLMAuthentication to
TIdNTLMAuthentication?
Also, what about TIdDigestAuthentication? I have seen, from the source code,
that it's not registered (in the initialization section). Still, is there a
working version of the digest method?
Alan.
Grahame Grieve
> "Grahame Grieve" <grra...@kestral.com.au> wrote in message
> news:40044424$1...@newsgroups.borland.com...
> > // where FAuthClass is of type TIdAuthenticationClass
> > // you have to know what this is and set it correctly
> > // for NTLM I Use TIdSSPINTLMAuthentication from
> > IdAuthenticationSSPI
>
> By the way, why do you prefer TIdSSPINTLMAuthentication to
> TIdNTLMAuthentication?
NTLM didn't work for me - something to do with versions?
SSPI always works
> Also, what about TIdDigestAuthentication? I have seen, from the
> source code, that it's not registered (in the initialization
> section). Still, is there a working version of the digest method?
the server I was using didn't use it
Grahame
Alex Brainman
> By the way, why do you prefer TIdSSPINTLMAuthentication to
> TIdNTLMAuthentication?
That longish post of mine http://tinyurl.com/3y73q might help you with the answer.
Alex
Alan Garny
news:4004ea01$1...@newsgroups.borland.com...
Thanks, I will have a look at it.
Alan.
jason
I've watched and participated with this and other threads on
the idHTTP component in Indy and the difficulties getting it to
work with proxy environments.
I have successfully managed to get the idHTTP component to
navigate through a proxy server with both Basic and NTLM
authentication.
I have found however that the Digest authentication (as
predicted by Doychin from Indy) does not work and still has a
ways to go. I have posted to the Indy guys regarding this only
recently.
So after much stuffing around trying to download and install
MS ISA server to test NTLM authentication I gave up and googled
for an alternative. Hey presto there was a FREE proxy server
that can handle Basic, Digest and NTLM authentication that runs
on "Windows 98, Windows NT with SP4, Windows 2000 Professional,
Windows 2000 Server, Windows XP Pro, Windows XP Home, or
Windows 2003 server" (I cut and past that section straight from
the help. Which I might add is more comprehensive than I have
seen from most commercial applications.) Link below:
http://www.alphalink.com.au/~gregr/freeproxy.zip
The main issues that I've seen facing developers with
idHTTP/Proxy issues on this and many other groups are :
1. Not enough knowledge about how proxies work; and
2. Indy documentation and code examples are not specific enough
regarding authentication for the uninitiated.
Point 1. above is dealt with by the comprehensive help and
overview on proxy servers in the freeproxy app above. Point 2.
is dealt with below.
Now to the enlightening part, the code. Just so you know my
development environment is Delphi 6 Ent, and Indy 9.0.14.
Just so you are aware, the following section of code only deals
with Proxy authentication, not HTTP authentication.
1. Make sure you add IdAuthenticationDigest.pas,
IdAuthenticationSSPI.pas, idSSPI.pas and IdHeaderList.pas are
in added to your Delphi project.
****VERY IMPORTANT****
Make sure that IdAuthenticationDigest and IdAuthenticationSSPI
appear in the "uses" clause of same unit that your idHTTP
component appears in. In my case I put the TidHTTP component in
my DataModule and my DataModules "uses" clause looked like
........
implementation
uses Registry, IdAuthenticationDigest,
IdAuthenticationSSPI, BasicProxyLogin;
{$R *.dfm}
........
I alse had to add the IdAuthentication and IdHeaderList to my
interface "uses" clause as well.
2. Set idHTTP.HTTPOptions.hoInProcessAuth := true;
This property should be set at design time and left as it tells
the proxy server to keep a connection alive during the
authorisation process. (Gambit thanks for that one!)
3. Load proxy server Port and Server settings with
idHTTP.ProxyParams.ProxyPort := whatever port it is;
idHTTP.ProxyParams.ProxyServer := IP address of proxy server;
Don't worry about username and password values yet, you can
wait for the proxy server to ask for them in the next step.
4. idHTTP.Get( aURL );
Go and request the URL you are after via the proxy server.
5. A idHTTP.Get( aURL ) command is sent to the proxy server and
the proxy server sends a response to the client (your app!!)
telling your app that it requires authentication before it will
let it go through the proxy. To set the correct authentication
type and parameters, you put your code in the
idHTTP.OnSelectProxyAuthorization event. This event passes
back information from to proxy that tells you what proxy
authentication method is required. I have posted the code that
I used to set up Basic/Digest/NTLM authentication below...
procedure TDataMod.IdHTTPSelectProxyAuthorization(Sender: TObject;
var AuthenticationClass: TIdAuthenticationClass;
AuthInfo: TIdHeaderList);
begin
// First check for NTLM authentication, as you do not need to
// set username and password because Indy will automatically
// handle passing your Windows Domain username and
// password to the proxy server
if (pos('Proxy-Authenticate: NTLM', idHTTP.Response.RawHeaders.Text) > 0) then
begin
idHTTP.ProxyParams.Clear;
idHTTP.ProxyParams.BasicAuthentication := false;
// Set the authentication class to NTLM
AuthenticationClass := TIdSSPINTLMAuthentication;
end
else
begin
// Next check for Basic
if (pos('Proxy-Authenticate: Basic', idHTTP.Response.RawHeaders.Text) > 0) then
begin
AuthenticationClass := TIdBasicAuthentication;
idHTTP.ProxyParams.BasicAuthentication := true;
end
else
begin
// Then Digest
if (pos('Proxy-Authenticate: Digest', idHTTP.Response.RawHeaders.Text) > 0) then
AuthenticationClass := TIdDigestAuthentication
end;
// Open up the table that holds my proxy settings
if tblFirewallFTP.Active = false then
tblFirewallFTP.Open;
tblFirewallFTP.First;
// Detect if the user has already entered these details
if (tblFirewallFTP.FieldByName('FWUserID').AsString <> '') then
begin
idHTTP.ProxyParams.ProxyUsername := tblFirewallFTP.FieldByName('FWUserID').AsString;
idHTTP.ProxyParams.ProxyPassword := tblFirewallFTP.FieldByName('FWPassword').AsString;
end
else
// if not, show a username and password capture window
// allowing the user to input these values.
begin
try
frmBasicProxyLogin := TfrmBasicProxyLogin.Create(application);
frmBasicProxyLogin.Caption := 'Proxy server authentication required..';
if frmBasicProxyLogin.ShowModal = mrOK then
begin
if tblFirewallFTP.Active = false then
tblFirewallFTP.Open;
tblFirewallFTP.First;
if (tblFirewallFTP.FieldByName('FWUserID').AsString <> '') then
begin
idHTTP.ProxyParams.ProxyUsername := tblFirewallFTP.FieldByName('FWUserID').AsString;
idHTTP.ProxyParams.ProxyPassword := tblFirewallFTP.FieldByName('FWPassword').AsString;
end;
end;
finally
frmBasicProxyLogin.Free;
end;
end;
end;
end;
In summary, the code above doesn't cater for incorrect username
and password, so you should enable a configuration area for
you users to change these details.
Again to the pro's out there this topic may seem quit trivial,
but I had issues determining what settings to set when...
For the others out there like me (ie. I'm not a pro) I hoped
I've made life a little easier.
Cheers,
Jason.
P.S. I encourage you to download the FreeProxy server I refered
to earlier. Certainly easier than setting up MS ISA server. I
was actually lucky enough to talk with the guy
who developed it earlier tonight. Who was more than happy to
provide support for a free product virtually straight-away. If
you need it the link again is below...
http://www.alphalink.com.au/~gregr
Grahame Grieve
Grahame
Theo Carr-Brion
Using your code if I try to connect to a HTTP site it selects NTLM
authorization and then a bit later I get socket error 10060 connection timed
out. If I connect to a HTTPS site it never even gets to the
OnSelectProxyAuthorization event. Have you tried a HTTPS site?
Theo Carr-Brion
"jason" <jason@sportschanbara_removethis.com.au> wrote in message
news:40068e35$1...@newsgroups.borland.com...
Alan Garny
news:40068e35$1...@newsgroups.borland.com...
> IdAuthenticationSSPI.pas, idSSPI.pas and IdHeaderList.pas are
> in added to your Delphi project.
Are you saying that you use IdAuthenticationDigest.pas? I thought that the
digest method had not been tested?...
> 2. Set idHTTP.HTTPOptions.hoInProcessAuth := true;
> This property should be set at design time and left as it tells
> the proxy server to keep a connection alive during the
> authorisation process. (Gambit thanks for that one!)
Nice one indeed.
> procedure TDataMod.IdHTTPSelectProxyAuthorization(Sender: TObject;
> var AuthenticationClass: TIdAuthenticationClass;
> AuthInfo: TIdHeaderList);
> begin
> ...
> end;
It is not clear to me why you don't use AuthInfo instead of
idHTTP.Response.RawHeaders.Text to determine which authentication method is
to be used...
Also, are you 100% sure that the header starts with 'Proxy-Authenticate:
NTLM' for an NTLM authentication method? I have done some tests with a proxy
and the header started with 'Basic' straight away, no 'Proxy-Authenticated:
Basic'. In other words, should I use your code with that proxy server, it
would break...
Finally, looking at the IdHTTP.pas file, I noticed that the component finds
whether the proxy server uses one of the methods supported by Indy. In other
words, and unless I am mistaken, there is no need to select the
authentication method, as long as it is Basic or NTLM (I don't include
Digest, since it has not been tested), and as long as you have included them
in the Uses clause (as you mentioned above).
In other words, the way I personally handle OnSelectProxyAuthorization is as
follows:
procedure TCommonModule.IdHTTPSelectProxyAuthorization(Sender: TObject;
var AuthenticationClass: TIdAuthenticationClass;
AuthInfo: TIdHeaderList);
Var
AuthMethod: String;
begin
If (AuthenticationClass = Nil) Then Begin
// There doesn't exist any authentication method that we can handle,
so...
AuthMethod := Copy(AuthInfo.Text, 1, Pos(' ', AuthInfo.Text)-1);
If (AuthMethod = '') Then Begin
// Couldn't extract the authentication method information, so get
the
// whole thing...
AuthMethod := AuthInfo.Text;
// Remove any trailing CR or LF
While (AuthMethod[Length(AuthMethod)] = _CR_) Or
(AuthMethod[Length(AuthMethod)] = _LF_) Do
AuthMethod := Copy(AuthMethod, 1, Length(AuthMethod)-1);
End;
ProxyErrorMsg := 'your proxy server uses an authentication method
('+AuthMethod+') that cannot be handled by '+CORName+'.';
End;
end;
Note: ProxyErrorMsg is just a part of the message that display when the
exception is raised for not being able to authenticate.
Also, I set the username/password somewhere else, hence it's not present
here.
Final note, as some of you know, I am no expert in proxy servers (to say the
least! :)), so please feel free to correct me if I am wrong...
Alan.
jason
Sorry for the late reply. I've been focused on another area of my software. To answer your question no I haven't tried HTTPS with the code I posted.
Cheers,
Jason.