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
in6addr_any), which comes from the
TIdSocketHandle.IPproperty, which is updated after binding. If the socket is bound to a specific local IP and not to in6addr_any, the
TIdSocketHandle.IPproperty 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.
OnStatus (with hsConnecting) will be fired, then
OnStatus again (with hsConnected),
OnWorkBegin (AWorkCountMax = 2609),
OnWork (AWorkCount = 2609) and
OnWorkEnd as last... No
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 :(
BasicAuthenticationhas 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
Proxy-Authenticateheaders. If you plan on having TIdHTTP handle authentication,
hoInProcessAuthshould 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
OnHeadersAvailableevent, for instance. If
hoInProcessAuthis not set, you have to handle authentication manually by checking the
TIdHTTP.ResponseCodeand then setting the
TIdHTTP.Request.CustomHeaders.Values['Authorization']on the next request.
hoInProcessAuth = Trueand
BasicAuthentication = Falseand retry the GET request.
MaxAuthRetriesis still on default = 3) request instead of 1. Every request still has a basic proxy-authorization set.
BasicAuthentication=True, or the server actually requests
Proxy-Authenticate, or you force
TIdBasicAuthenticationdirectly. When TIdHTTP receives 407, the only ways that
OnSelectProxyAuthorizationwould not be triggered are either 1)
MaxAuthRetries, or 2)
ProxyParams.Authenticationis already assigned an auth class. After an auth class has been assigned, the only ways that
OnProxyAuthorizationwould not be triggered are either 1)
ProxyParams.ProxyPasswordis blank, or 2) the authentication class doesn't request user input (
TIdAuthentication.Next()does not return
wnAskTheProgram). You are going to have to step into Indy's souce code with the debugger to figure out what TIdHTTP is really doing during its 407 processing. TIdHTTP should be handling the retry requests for you. Make sure the credentials you are using are accurate. If they are not working, maybe the NTLM request is being malformed, so the proxy keeps rejecting it.