rlebeau on master
upgraded Delphi XE projects by … added Delphi XE project group Merge pull request #411 from co… (compare)
procedure TNetworkingModel.ConfigureUDPBindings(const AListener: TIdIPMCastClient);
var
LHandle: TIdSocketHandle;
I: Integer;
begin
AListener.Bindings.Clear;
for I := 0 to FLocalAddresses.Count - 1 do
begin
LHandle := AListener.Bindings.Add;
LHandle.IPVersion := FLocalAddresses.Addresses[I].IPVersion;
LHandle.IP := FLocalAddresses.Addresses[I].IPAddress;
LHandle.Port := AListener.DefaultPort;
end;
end;
procedure TForm1.SendBroadcast(const AServer: TIdIPMCastServer; const ABroadcast: string);
var
I: Integer;
begin
for I := 0 to FLocalAddresses.Count - 1 do
begin
if FLocalAddresses[I].IPVersion = AServer.IPVersion then
begin
AServer.Active := False;
AServer.BoundIP := FLocalAddresses[I].IPAddress;
AServer.BoundPort := AServer.Port;
AServer.Active := True;
AServer.Send(ABroadcast);
end;
end;
end;
setsockopt()
when adding a local IP to the multicast group, which is done after the socket is bound locally. The local IP that is being passed in is 0:0:0:0:0:0:0
(aka in6addr_any
), which comes from the TIdSocketHandle.IP
property, which is updated after binding. If the socket is bound to a specific local IP and not to in6addr_any, the TIdSocketHandle.IP
property should not be all zeros. That implies a possible failure in TIdSocketHandle.UpdateBindingLocal()
. But no matter, because the local IP is not currently being passed to setsockopt(IPV6_ADD_MEMBERSHIP)
in IPv6, it is set to the default multicast interface instead. Maybe that is what iOS is complaining about.
I have still problems with HTTP and NTLM Proxy :( IdAuthenticationNTLM, IdAuthenticationSSPI, IdAuthenticationDigest are used in the interface uses section
For debugging I created event handler for every event of TIdHTTP with logging all method parameters.
First OnStatus
(with hsConnecting) will be fired, then OnStatus
again (with hsConnected), OnHeadersAvailable
, OnWorkBegin
(AWorkCountMax = 2609), OnWork
(AWorkCount = 2609) and OnWorkEnd
as last... No OnProxyAuthorization
or OnSelectProxyAuthorization
is called!
The received header is
Proxy-Authenticate: Negotiate
Proxy-Authenticate: NTLM
Date: Tue, 06 Jun 2017 09:07:12 GMT
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset="UTF-8"
Content-Length: 2609
Accept-Ranges: none
Proxy-Connection: keep-alive
The component will be created via
LHttp := TIdHTTP.Create(nil);
LHttp.ProxyParams.ProxyServer := LProxy.ProxyServer;
LHttp.ProxyParams.ProxyPort := LProxy.ProxyPort;
if LProxy.UseAuthentification then
begin
LHttp.ProxyParams.BasicAuthentication := True;
LHttp.ProxyParams.ProxyUsername := LProxy.Username;
LHttp.ProxyParams.ProxyPassword := LProxy.Password;
end;
LHttp.Request.UserAgent := 'My Client ' + CVersion; // WebServer will always accept this user agent
LHttp.OnAuthorization := HTTP1Authorization;
LHttp.OnChunkReceived := HTTP1ChunkReceived;
LHttp.OnConnected := HTTPConnected;
LHttp.OnDisconnected := HTTPDisconnected;
LHttp.OnHeadersAvailable := HTTP1HeadersAvailable;
LHttp.OnProxyAuthorization := HTTP1ProxyAuthorization;
LHttp.OnRedirect := HTTP1Redirect;
LHttp.OnSelectAuthorization := HTTP1SelectAuthorization;
LHttp.OnSelectProxyAuthorization := HTTP1SelectProxyAuthorization;
LHttp.OnStatus := HTTP1Status;
LHttp.OnWork := HTTP1Work;
LHttp.OnWorkBegin := HTTP1WorkBegin;
LHttp.OnWorkEnd := HTTP1WorkEnd;
LHttp.Get(LUrl, LFileStream, [CAccepted_WebServerResponses]);
Did I miss something?
I also have Wireshark logs of the Get-Trys. The first Get from Indy sends already a Proxy-Authorization in Basic, is that correct? But Answer is always HTTP/1.1 407 Proxy Authorization required
and there is no more traffic, no second attampt is maded. My biggest problem is, I have no test enviremont. Every change I do, I have to create a new binary and give it to a customer (which knows that they are experimental and, for now, is happy to be a alpha tester).
MauxAuthRetries
= 42. No success :(
BasicAuthentication
has to be set before you send a request, since it helps govern the type of authentication sent in the request. The only way to determine the server's desired authentication type(s) is to send a request, even if just HEAD
, and see how the server responds. The authentication(s) are specified in the response's WWW-Authenticate
and Proxy-Authenticate
headers. If you plan on having TIdHTTP handle authentication, hoInProcessAuth
should always be set. At the very least, it needs to be set before the response is parsed, so you could set it dynamically in the OnHeadersAvailable
event, for instance. If hoInProcessAuth
is not set, you have to handle authentication manually by checking the TIdHTTP.ResponseCode
and then setting the TIdHTTP.Request.Authentication
or TIdHTTP.Request.CustomHeaders.Values['Authorization']
on the next request.
hoInProcessAuth = True
and BasicAuthentication = False
and retry the GET request.MaxAuthRetries
is still on default = 3) request instead of 1. Every request still has a basic proxy-authorization set.