Leaderboard

I get massive logs from so called internet research companies probing my servers, I have about 40 public IP4s in three subnets and any servers listening are attacked daily, the firewalls try to restrict how many ports and IPs can be accessed, but all public servers suffer. ICS has a TIcsBlackList component that most of my servers use, any HTTP request by IP address is immediately blocked for 24 hours and new connections closed, well known IP ranges are permanently blocked, etc. So checking for non-SSL connections on SSL ports would be a useful addition. I'll experiment adding it to TSslSocketServer. Angus

Yeah. I could maybe forgive them their general incompetence as it's probably caused by a lack of resources - but that lie is just insulting.

It's ironic that the download spikes caused by all the Delphi 12 downloads have caused this

You call GetLastError after the Create call. It will return ERROR_ALREADY_EXISTS if the named semaphore already exists. That also applies to other named synchronization objects, like mutexes. See the API function CreateSemaphoreW. TSemaphore inherits a property LastError from THandleObject, it may serve as well.

Several hardware problems at the same moment? My imagination offers me something like this: (image found on the web, not from Emba!)

I've asked ChatGPT. He proposed this: To authenticate with Microsoft 365 and send emails through Exchange Online, you can use the Microsoft Graph API to obtain an access token, and then include that access token in the HTTP headers when sending the email. Here's an example Delphi code that shows how to do this: delphi Copy code uses System.Net.URLClient, System.Net.HttpClient, System.Net.HttpClientComponent; procedure SendEmail; var AuthToken: string; Http: TNetHTTPClient; Request: TNetHTTPRequest; Response: IHTTPResponse; Body: TStringStream; begin // First, obtain an access token using the Microsoft Graph API. Http := TNetHTTPClient.Create(nil); try Body := TStringStream.Create('grant_type=client_credentials&client_id=<your_client_id>&client_secret=<your_client_secret>&scope=https://graph.microsoft.com/.default'); try Response := Http.Post('https://login.microsoftonline.com/<your_tenant_id>/oauth2/v2.0/token', Body, nil); try if Response.StatusCode = 200 then begin AuthToken := TJSONObject.ParseJSONValue(Response.ContentAsString).GetValue<string>('access_token'); end else begin // Handle error. Exit; end; finally Response := nil; end; finally Body.Free; end; finally Http.Free; end; // Now, send the email using the access token. Http := TNetHTTPClient.Create(nil); try Request := TNetHTTPRequest.Create(nil); try Request.Method := TNetHTTPRequest.TMethod.rmPOST; Request.URL := 'https://graph.microsoft.com/v1.0/me/sendMail'; Request.ContentType := 'application/json'; Request.CustomHeaders['Authorization'] := 'Bearer ' + AuthToken; Request.Source := TStringStream.Create('{ ' + '"message": {' + '"subject": "Test email",' + '"body": {' + '"contentType": "Text",' + '"content": "This is a test email."' + '},' + '"toRecipients": [{' + '"emailAddress": {' + '"address": "<recipient_email_address>"' + '}' + '}]' + '},' + '"saveToSentItems": "true"' + '}', TEncoding.UTF8); Response := Http.Execute(Request); try if Response.StatusCode <> 202 then begin // Handle error. end; finally Response := nil; end; finally Request.Free; end; finally Http.Free; end; end; Replace <your_client_id>, <your_client_secret>, <your_tenant_id>, and <recipient_email_address> with your own values. Note that you'll need to register an application in the Azure Portal and grant it the appropriate permissions to use the Microsoft Graph API

I have implemented this kind of logic before, but only in plain socket code (though I suppose it can be applied to socket libraries like ICS or Indy, too). It requires the TLS server to peek not recv the first few bytes of a new connection, and only if those bytes belong to the header of a TLS handshake then enable TLS on that connection (allowing the previously-peeked bytes to now be read by whatever TLS library you use), otherwise don't enable TLS on the connection and just read the connection raw.

The main issue in implementing your dual protocol concept is pre-reading the initial data received from the client, and then resetting so that it's read a second time after initialising SSL. That will be messy with our event driven structure. Angus

Hi All Anyone know of a tool that can fix up unit namespaces in the uses clause, ie change uses sysutils, stdctrls; to uses System.SysUtils, Vcl.StdCtrls; I have a few thousand units to go through and clean up, I've tried regex etc but it's not reliable enough.

Meanwhile the project is on GitHub: https://github.com/UweRaabe/UsesCleaner You don't even need to change the sources to handle FMX. The -c command line parameter lets you specify a configuration file with your preferred settings. An example can be found on GitHub.

I have multiple projects that are heavily dependent on DWScript and I like to think I'm a bit of a DWScript expert after having used it for so many years (since 2002). However... It's a bit hard for me to judge if the implementation is "very clean" because the source is close to unreadable to me. The architecture might be solid but I have spent hours trying to solve problems by reading the source and the non-standard code style and the lack of comments in the code means it's futile to try to learn from the source. It has improved since DWS2 but not enough. Another problem is that there's zero documentation and the examples only covers very basic use cases. So expect a steep learning curve. Finally there's no community and it's maintained by a single person who doesn't seem interested in letting anyone else work on it. But apart from all that I can also recommend DWScript. Here's an IDE for DWScript if you need it: https://bitbucket.org/anders_melander/dwscriptstudio

DWSScipt is my favorite. Its syntax is modern, and its implementation is very clean. It even has a JIT! The problem is that it is not cross-platform yet. The veteran PascalScript is my favorite if cross-platform is needed. It is stable, and widely used since years.

I just got done with this and it just worked! I did have to modify the hard coded path for the UsesHelper.SearchPath to match the delphi version I'm using. I tested first by specifying an output directory, and after checking with beyond compare to see how it did, I just processed the original files. It did also introduce some compilation errors, where I have prefixed function calls with the unit names (e.g SysUtils.DeleteFile ), simple to fix though. Thanks @Uwe Raabe

I have written a tool including that functionality some time ago. Although I didn't find the time to polish it up before going public, it basically does what it is supposed to. Expanding unit scope names is only part of the whole process, which consists of resolve all unit aliases expand unit scope names group units compress uses clause Taking your example above it will convert uses sysutils, stdctrls; into uses System.SysUtils, Vcl.StdCtrls; Feel free to adjust the sources to your needs. UsesCleanerSource.zip

GExperts has this functionality, but only for the current unit. Feel free to use that code to build a batch tool (it's not quite so easy since you must take the project settings and search paths into account). I'll accept patches, of course. 😉