TIdHTTP and XML integration (API)

[rhcarpenter]

I am not proficient with the Indy components.  Years ago I researched and struggled and finally got the following to work.  This code calls an API to get an authorization code.   Look at the code and then please continue reading the information following.

  HTTP := TIdHTTP.Create(nil);
  try
    SSL := TIdSSLIOHandlerSocketOpenSSL.Create(HTTP);
    // configure SSL options as needed...
    HTTP.IOHandler := SSL;
    FResponseText := Trim(HTTP.Get('https://evs.e2value.com/evs/remote_auth.asp?username=' + TIdURI.ParamsEncode(username)
      + '&password=' + TIdURI.ParamsEncode(password) + '&vusername=' + TIdURI.ParamsEncode(vusername)));

    (* Parse the document *)
    XMLDocument1.XML.Clear;
    XMLDocument1.XML.Add(Trim(FResponseText));
    XMLDocument1.Active := True;
    AuthId := XMLDocument1.DocumentElement.ChildNodes[0].Text;
    if Copy(AuthId, 1, 5) = 'Sorry' then
      raise Exception.Create('Unable to authenticate.  Bad username or password.')
    else
      if Copy(AuthId, 1, 14) = 'Please provide' then
        raise Exception.Create('Unable to authenticate.  Bad password.');
    AuthCode := XMLDocument1.DocumentElement.ChildNodes[1].Text;
  finally
    XMLDocument1.Active := False;
    SSL.Free;
    HTTP.Free;
  end;


The code no longer works.  It breaks on the line

    FResponseText := Trim(HTTP.Get('https://evs.e2value.com/evs/remote_auth.asp?username=' + TIdURI.ParamsEncode(username)
      + '&password=' + TIdURI.ParamsEncode(password) + '&vusername=' + TIdURI.ParamsEncode(vusername)));

and then of course jumps to the code within the "finally" section.  A couple of weeks ago I received the notice below from the owners of the API.  How do I change my code to make it work?  Can I make it work?  Any help you can provide will be greatly appreciated.


Effective October 1, 2018 we will no longer accept any HTTP requests via XML Integration, also known as API. We will only accept HTTPS requests.
 
Internet Security is a significant concern for us. To offer the best security we can, e2Value continually updates protocols. There have been a number of worldwide changes this year that seem to have caused disruptions for some clients.
 
Any steps we take are to protect ourselves—and more importantly—our customers. None of the security protocols we have instituted or will institute in the future are ones that e2Value decided independently. We were merely complying with the standards we are expected to maintain by and for our customers.
 
Among our recent updates is the requirement of Transport Layer Security (TLS) 1.2 communication with our servers, as the latest security guidelines recommend. TLS 1.2 encryption protocol helps keep data safe during its transmission over the internet.
 
We renew our SSL certificates annually.
 
SSL certificates are either valid or expired and they should be read by a customer’s server during the actual transaction—not stored on the customer’s servers.
 
Storing them on one’s server is typically done because the server has an HTTP connection versus an HTTPS connection. That HTTP connection is an unsecure link that will be blocked after September 30, 2018. To that end:
 

1. Any HTTP connections will be severed starting October 1, 2018.
   
2. If you have an HTTP connection in any postback, you may want to have a security review of your connections, e2Value’s and others, if applicable.
   
3. We recommend no one store the SSL certificates.
   
4. If a certificate is stored, note and diary the SSL expiration date. We will not be sending out future notices about expiring certificates.
   

 
These updates should only affect integrated accounts—Single Sign-on, Basic Portico, Advanced Portico and XML (API) integrations—not direct login accounts



Again any help will be greatly appreciated.

Randall H. Carpenter