TIdStackVCLPosix.GetLocalAddressList fails to retrieve any addresses for me on my Android 7 device, so I've created this Gist, in case it's of any use:
https://gist.github.com/DelphiWorlds/0733b6611707c8d5725ee42fd1ae01fd
https://gist.github.com/DelphiWorlds/0733b6611707c8d5725ee42fd1ae01fd
@DelphiWorlds TIdStackVCLPosix.GetLocalAddressList() being broken on Android is a known issue. There are comments to that effect in the code. I stay away from using Embarcadero's JNI Bridge interfaces because 1) they are not portable (they only work in Delphi, not in FreePascal), and 2) there are threading issues related to accessing Java objects in native code, so I try to stick with native solutions. Which I have not implemented for Android yet.
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;
For now I'll assume it's because the MulticastGroup value is invalid.. I'm far from a multicast expert, too ;-)
Exact error message again:
Project dyld_sim raised exception class EIdSocketError with message 'Socket Error # 49
Cannot assign requested address.'.
Project dyld_sim raised exception class EIdSocketError with message 'Socket Error # 49
Cannot assign requested address.'.
Call stack:
System._DbgExcNotify(0,$C9B3010,$909364 {'EIdSocketError'},$6306C8,nil)
System.NotifyReRaise
:00017cc7 NotifyReRaise + $13
IdStack.TIdStack.RaiseSocketError(49)
IdStack.TIdStack.RaiseLastSocketError
IdStack.TIdStack.CheckForSocketError(-1)
IdStackVCLPosix.TIdStackVCLPosix.SetSocketOption(9,41,12,(no value),20)
IdStackBSDBase.TIdStackBSDBase.MembershipSockOpt(9,???,'0:0:0:0:0:0:0:0',12,Id_IPv6)
IdStackBSDBase.TIdStackBSDBase.AddMulticastMembership(9,'FF01:0:0:0:0:0:0:1','0:0:0:0:0:0:0:0',Id_IPv6)
IdSocketHandle.TIdSocketHandle.AddMulticastMembership('FF01:0:0:0:0:0:0:1')
:00633c46 TIdSocketHandle.AddMulticastMembership + $3A
IdIPMCastBase.TIdIPMCastBase.SetActive(True)
Multicast.TMulticastModule.EnableServices(True)
Multicast.TMulticastModule.Create($D820800)
System._DbgExcNotify(0,$C9B3010,$909364 {'EIdSocketError'},$6306C8,nil)
System.NotifyReRaise
:00017cc7 NotifyReRaise + $13
IdStack.TIdStack.RaiseSocketError(49)
IdStack.TIdStack.RaiseLastSocketError
IdStack.TIdStack.CheckForSocketError(-1)
IdStackVCLPosix.TIdStackVCLPosix.SetSocketOption(9,41,12,(no value),20)
IdStackBSDBase.TIdStackBSDBase.MembershipSockOpt(9,???,'0:0:0:0:0:0:0:0',12,Id_IPv6)
IdStackBSDBase.TIdStackBSDBase.AddMulticastMembership(9,'FF01:0:0:0:0:0:0:1','0:0:0:0:0:0:0:0',Id_IPv6)
IdSocketHandle.TIdSocketHandle.AddMulticastMembership('FF01:0:0:0:0:0:0:1')
:00633c46 TIdSocketHandle.AddMulticastMembership + $3A
IdIPMCastBase.TIdIPMCastBase.SetActive(True)
Multicast.TMulticastModule.EnableServices(True)
Multicast.TMulticastModule.Create($D820800)
the same code works on Windows.. but I'm guessing that may be irrelevant given differences in OS
@DelphiWorlds The error is coming from
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.
Looks like the interface number does matter
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-aliveThe 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).
I also tried to send a second GET after the first failed one with
MauxAuthRetries = 42. No success :(
(Only a lot of more traffic in the wireshark log, but all the same as the first try: Indy only sends a GET with basic authentication and proxy answers with 407)
@mezen
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, 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 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.
Or, now tried this: First GET request is as shown above. If I get a 407 back I set
Wireshark now says Indy send 4 (
hoInProcessAuth = True and BasicAuthentication = Falseand retry the GET request.Wireshark now says Indy send 4 (
MaxAuthRetries is still on default = 3) request instead of 1. Every request still has a basic proxy-authorization set.
@mezen TIdHTTP will not send a
BASIC request unless BasicAuthentication=True, or the server actually requests Basic in WWW-Authenticate or Proxy-Authenticate, or you force Request.Authentication or ProxyParams.Authentication to TIdBasicAuthentication directly. When TIdHTTP receives 407, the only ways that OnSelectProxyAuthorization would not be triggered are either 1) AuthProxyRetries has exceeded MaxAuthRetries, or 2) ProxyParams.Authentication is already assigned an auth class. After an auth class has been assigned, the only ways that OnProxyAuthorization would not be triggered are either 1) ProxyParams.ProxyPassword is 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.
I'm back on the multicast thing.. abandoned IPv6 support for now, however my test project works on Android and Windows, but not iOS
that still sucks, however
Hello! I see there's some chat about TIdHTTP and NTLM proxy handling in the chat since I last visited -- as it turns out I've run into something related this morning and have possibly a stupid question. The code in question tries to do a request via a proxy to "https://www.google.com", now it turns out that it had a slight flaw in that it was attempting to check the responsecode (expecting 200) but wasn't getting to see it because TIdHTTP.HTTPOptions did not contain hoNoProtocolErrorException, and for whatever reason the proxy server in question is now returning 407 so Indy was now throwing an exception as would be expected. Fine, so I added this into the TIdHTTP.HTTPOptions. However now the program ran into a seeming infinite loop inside the TIdHTTP code, and at first glance I don't understand how this is meant to work. Specifically in IdHTTP.pas line 2029 (Delphi 10.1 Berlin Indy), inside method "ConnectToHost" there is repeat until loop coded with "False" as the condition. Now obviously this loop will continue infinitely unless an exception is thrown, however with the code as it is currently (since adding hoNoProtocolErrorException) this does not happen and I seem to have what should (I would think) never happen -- an infinite loop in some library code? What am I doing wrong, and can anyone explain why this loop is hardcoded with "False" as the terminating condition?? Further background: I'm getting back a 407 from the proxy server, which I'm simply expecting to be able to detect in the client code by inspecting the TIdHTTP.ResponseCode. This code was supposedly working with SSPINTLM (based on comment in the code) though looking at it now I'm sort of dubious. It's possible the proxy server in question has had its config changed as well, I haven't followed this up yet either. But firstly, I'd like to understand why I'm not (at least) getting back a detectable 407 in the code (and am instead stuck in an infinite loop inside Indy?!)
The test code in question are as follows (warts and all):
var
LIdHTTP : TIdHTTP;
LSSLIOHandler : TIdSSLIOHandlerSocketOpenSSL;
LRequestStr, LResult : String;
begin
LRequestStr := 'https://www.google.com';
LIdHTTP := TIdHTTP.Create(nil);
try
// Setup of TidHTTP that supposedly works with Squid SSPINTLM authentication.
LSSLIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(LIdHTTP);
LSSLIOHandler.SSLOptions.Method := TIdSSLVersion.sslvTLSv1_2;
LIdHTTP.IOHandler := LSSLIOHandler;
LIdHTTP.HandleRedirects := True;
LIdHTTP.AllowCookies := True;
LIdHTTP.ConnectTimeout := 10000;
LIdHTTP.ReadTimeout := 10000;
LIdHTTP.Request.BasicAuthentication := True;
LIdHTTP.HTTPOptions := LIdHTTP.HTTPOptions + [hoKeepOrigProtocol] + [hoInProcessAuth] + [hoNoProtocolErrorException] + [hoWantProtocolErrorContent];
LIdHTTP.ProtocolVersion := pv1_1;
LIdHTTP.ProxyParams.ProxyServer := 'proxy';
LIdHTTP.ProxyParams.ProxyPort := 3128;
LResult := LIdHTTP.Get(LRequestStr);
CheckEquals(200, LIdHTTP.ResponseCode);
finally
LIdHTTP.Free;
end;
end;
@ByteJuggler 407 is how a proxy asks the client for authentication. That will trigger the
TIdHTTP.OnSelectProxyAuthorization event if the TIdHTTP.ProxyParams.Authentication property is not assigned, and then the TIdHTTP.OnProxyAuthorization event to ask for new credentials if needed. Neither of which you have assigned event handlers to. If authentication cannot be performed at all (unsupported auth scheme, no credentials provided, retry limit reached, etc), TIdHTTP should exit if hoNoProtocolErrorException is set, otherwise it will raise an exception. If authentication can proceed, TIdHTTP will try to perform it if hoInProcessAuth is set, otherwise it should exit and you will have to send a new request with proxy authentication added.
@ByteJuggler The loop you refer to is only run if connected to an HTTP proxy using the HTTP
CONNECT verb. And yes, it is looped, because it may take multiple HTTP requests to satisfy authentication, HTTP redirects, etc. The loop is hard-coded to "False" because the number of iterations needed is unknown. The inner body of the loop needs to decide when to exit the loop. hoNoProtocolErrorException was never intended to be used with proxy handling. The loop in question does not look at the return value of LLocalHTTP.ProcessResponse to break the loop if needed. A similar loop is in TIdCustomHTTP.DoRequest(), but it does look at the return value and act accordingly. So similar logic will have to be added to TIdCustomHTTP.ConnectToHost() when communicating with a proxy
@ByteJuggler until then, in your example, you can disable
hoNoProtocolErrorException and hoWantProtocolErrorContent, and then catch the raised EIdHTTPProtocolException. The response code will be in the exception's ErrorCode property, and any body content will be in the ErrorMessage property.
Thanks for the response, very much appreciated. I only added hoNoProtocolErrorException (and hoWantProtocolErrorContent) this morning as otherwise the code below the Get() would never run etc. and when it failed, the raised exception didn't make it particularly obvious initially what had failed where (whereas having the Check like fail would've been rather more direct) so I thought I'd rather just stop the whole exception thing and check the result code, whatever it may be.
Anyway given what you've said however I'll remove these again and make do with catching the exception instead as suggested for now.
Aside from this I'm still puzzled about the test failing now with a 407 in the first place. I'm trying to understand and reconcile your explanation with the fact that this code was working previously through this proxy, and to add which works (still) with NTLMSSP via Chrome and Firefox with no problems.
So I'm slightly puzzled regarding the auth, how this worked at all in the past then, seemingly by some fluke, since if I understand you correctly you're implying that the above code could not auth properly against an NTLM proxy due to missing event handlers/properties? Or am I misunderstanding you? (I've added IdHTTPSSPI and IdHTTPNTLM units to the above code, which was previously missing to ensure these were registered but hasn't made a difference... shouldn't the presence of these units register the necessary handlers so that hoInProcessAuth makes Indy deal with the authentication? I'm obviously being stupid about something... sorry!)