the right way to authenticate, manage users - sessions
TIdHTTPServer manages HTTP sessions for you if you set the TIdHTTPServer.SessionState property to true (the default is false). TIdHTTPServer uses cookies to manage the session, so your customers must have cookies.
Authentication must be done manually, but how you do it depends on whether your clients use HTTP authentication or HTML authentication.
For HTTP authentication, the available properties ARequestInfo.UserName and ARequestInfo.Password are available. If not valid, send the corresponding 401 response back to the client (if you set the AResponseInfo.AuthRealm property AResponseInfo.AuthRealm non-empty string, TIdHTTPServer will send you a 401 response). By default, TIdHTTPServer only supports BASIC authentication. If you want to support other authentication schemes, you will need to use the TIdHTTPServer.OnParseAuthentication event and send a 401 response manually so that you can send the corresponding WWW-Authenticate headers. In any case, if the client is verified, you can use HTTP sessions so that the client registers between requests. The AResponseInfo.Session and AResponseInfo.Session indicate the current session. If TIdHTTPServer.AutoStartSession true (the default is false), TIdHTTPServer automatically creates new sessions. Otherwise, you can call TIdHTTPServer.CreateSession() yourself when necessary. TIdHTTPSession has a Content property in which you can store session related data. Or you can get a new class from TIdHTTPSession , and then use the TIdHTTPServer.OnCreateSession event to instantiate this class.
For HTML authentication, you have two options, depending on how you configure your HTML:
if your HTML <form> does not have an enctype attribute or if it is set to application/x-www-webform-urlencoded , TIdHTTPServer will store raw web form data in the ARequestInfo.FormParams property, and if TIdHTTPServer.ParseParams true (by default it is) , the data will also be analyzed in the ARequestInfo.Params property for you.
if your <form> has the enctype attribute set to multipart/form-data , you will have to manually analyze the contents of ARequestInfo.PostStream , since TIdHTTPServer has not yet analyzed this data for you (examples have been published many times earlier in different forums about how to manually analyze this data using the Indy class TIdMessageDecoderMIME ). By default, ARequestInfo.PostStream points to a TMemoryStream object. You can use the TIdHTTPServer.OnCreatePostStream event to instantiate another TStream -decay class, if necessary.
The main problem: the connection must be secure, so SSL encryption is required, how to implement it?
Before activating the server:
assign the TIdServerIOHandlerSSLBase -decoded component, such as TIdServerIOHandlerSSLOpenSSL , to the TIdHTTPServer.IOHandler property and configure it as needed (certificate, peer verification, SSL version, etc.). In the case of OpenSSL, you will need to deploy the two OpenSSL library executables libeay32.dll and ssleay32.dll (or non-Windows platform equivalents) with your application, if they have not already been pre-installed on the target OS, or if you want your application used a specific version of OpenSSL. OpenSSL is currently the only encryption that Indy supports natively, but there are third-party Indy-compatible solutions such as EldoS SecureBlackbox .
populate the TIdHTTPServer.Binding property TIdHTTPServer.Binding binding for your desired HTTPS port (443 is the default HTTPS port). Typically, you should create 2 bindings, one for HTTP port 80 and one for HTTPS port 443. Inside OnCommand... handlers, if you receive a request that requires SSL / TLS encryption, you can check the port on which the request was made ( AContext.Binding.Port ), and if HTTPS does not redirect ( AResponseInfo.Redirect() ) the client to re-request the request to the HTTPS port.
assign a handler to the TIdHTTPServer.OnQuerySSLPort event and set the VUseSSL parameter to True if its APort parameter matches your HTTPS port.