Proxy does not work any more after updating from 8.57 to 8.68

[M.e.l 1]

Hi,

After updating from v8.57 to 8.68,

the proxy setting in my TsslHttpCli component did not work anymore.

Proxy:  http://xxx.xxx.xxx.xxx:8080/wpad.dat

Port: 8080

ProxyUsername / ProxyPassword are also set

 

In unit OverbyteIcsHttpProt, function THttpCli.PrepareNTLMAuth(var FlgClean : Boolean) : Boolean;

 

I did revert that part:

8.68 code:

 

    { this flag can tell if we proceed with OnRequestDone or will try    }
    { to authenticate                                                    }
    Result := FALSE;
    if (httpoNoNTLMAuth in FOptions) and
       (((FStatusCode = 401) and (FServerAuth = httpAuthNtlm)) or
       ((FStatusCode = 407) and (FProxyAuth = httpAuthNtlm))) then
          Exit

    else if (FStatusCode = 407)    and (FDoAuthor.Count > 0) and
            (FProxyAuthBasicState = basicNone)
{$IFDEF UseDigestAuthentication}
            and (FProxyAuthDigestState = digestNone)
{$ENDIF}
            then begin  // V8.61  OAS : remove case where user and PW are empty because used for User credentials
        { We can handle authorization }
        TmpInt := FDoAuthor.Count - 1;
        while TmpInt >= 0  do begin
            if CompareText(Copy(FDoAuthor.Strings[TmpInt], 1, 4), 'NTLM') = 0 then begin
                Result := TRUE;
                if Assigned(FOnBeforeAuth) then
                    FOnBeforeAuth(Self, httpAuthNtlm, FALSE,
                                  FDoAuthor.Strings[TmpInt], Result);
                if Result then begin
                    if (FProxyUsername = '') and (FProxyPassword = '')  and not Assigned(FAuthNtlmSession) then  // V8.61
                        FAuthNtlmSession := TNtlmAuthSession.Create (cuOutbound) ;                               // Create session for proxy NTLM
                    StartAuthNTLM;
                    if FAuthNTLMState in [ntlmMsg1, ntlmMsg3] then
                        FlgClean := True;
                    Break;
                end;
            end;
            Dec(TmpInt);
        end;
    end

 

reverted to 8.57 code:

    { this flag can tell if we proceed with OnRequestDone or will try    }
    { to authenticate                                                    }
    Result := FALSE;
    if (httpoNoNTLMAuth in FOptions) and
       (((FStatusCode = 401) and (FServerAuth = httpAuthNtlm)) or
       ((FStatusCode = 407) and (FProxyAuth = httpAuthNtlm))) then
        Exit;

    if (FStatusCode = 401) and (FDoAuthor.Count > 0) and
       (FAuthBasicState = basicNone) and
{$IFDEF UseDigestAuthentication}
       (FAuthDigestState = digestNone) and
{$ENDIF}
       (FCurrUserName <> '') and (FCurrPassword <> '') then begin
        { We can handle authorization }
        TmpInt := FDoAuthor.Count - 1;
        while TmpInt >= 0  do begin
            if CompareText(Copy(FDoAuthor.Strings[TmpInt], 1, 4), 'NTLM') = 0 then begin
                Result := TRUE;
                if Assigned(FOnBeforeAuth) then
                    FOnBeforeAuth(Self, httpAuthNtlm, FALSE,
                                  FDoAuthor.Strings[TmpInt], Result);
                if Result then begin
                    StartAuthNTLM;
                    if FAuthNTLMState in [ntlmMsg1, ntlmMsg3] then
                        FlgClean := True;

                    Break;
                end;
            end;
            Dec(TmpInt);
        end;
    end

 

 

and... miracle: it did work again !! (with everything else from v8.68)....
 

I am NOT sure that is a bug:

I might have something wrong in my code leading to that and need to set some properties to my TSslHttpCli to avoid that...

But I don't know what...

 

if somebody can help,

thanks in advance

Mel

 

[Angus Robertson 574]

Bottom line is testing multiple variants of authentication and proxy settings is a nightmare, takes a long time to setup all the testing environments locally, so if you want this investigated we will need access to the proxy and server to which  ICS is failing to connect.  But won't have time to look for at least a week. 

 

The change three years ago was done by a user accessing a Windows domain with single sign on, but I guess not via a proxy, which I can not test.

 

Angus

 

[M.e.l 1]

Yes, I can imagine how that can be a nightmare...

But I am afraid I will not be able to provide any access to that proxy server, as this happens by a customer.

 

The problem is solved by patching back that part of code !

But I will try to investigate further.

 

Mel