mjustin

The Daraja HTTP Server Framework is a free open source library for Object Pascal (Free Pascal 3.2.0 or Delphi 2009+), based on the HTTP server component in Internet Direct (Indy). New: the 2.6-SNAPSHOT includes a first implementation of the Web Filter API, which allows pre- and postprocessing of HTTP requests and responses. Web Filters are useful for example to add logging and auditing, input validation, or authentication. Filters may be composed in filter chains, where the order of filter execution is defined by the order of registration. Web Filter instances may configured through init parameters. Example code In the test example below, the Web Component TExamplePage returns the plain-text response "example", and the filters (TTestFilterA and TTestFilterB) add the texts " (A)" and " (B)" to the response. The client therefore receives the response "example (A) (B)". Code: Pascal [Select][+] procedure TAPIConfigTests.TestTwoFilters; var Server: TdjServer; Context: TdjWebAppContext; begin Server := TdjServer.Create; try Context := TdjWebAppContext.Create('web'); // Context located at http://<server:port>/web/ Context.AddWebComponent(TExamplePage, '*.txt'); // Web Component responds to all requests for txt documents Context.AddWebFilter(TTestFilterA, TExamplePage); // Web Filter A will be processed first and appends " (A)" Context.AddWebFilter(TTestFilterB, TExamplePage); // Web Filter B will be processed second and appends " (B)" Server.Add(Context); Server.Start; CheckGETResponseEquals('example (A) (B)', '/web/test.txt'); finally Server.Free; end; end; Code for the DoFilter method of TTestFilterA: procedure TTestFilterA.DoFilter(Context: TdjServerContext; Request: TdjRequest; Response: TdjResponse; const Chain: IWebFilterChain); begin Chain.DoFilter(Context, Request, Response); // invoke other filters and eventually the Web Component Response.ContentText := Response.ContentText + ' (A)'; end; Full source code, including DUnit and FPCUnit tests, is available at GitHub. The Web Filter API specification is still in development and may still see minor and major changes. More information - GitHub: https://github.com/michaelJustin/daraja-framework - 2.6-SNAPSHOT API documentation: https://michaeljustin.github.io/daraja-framework/2.6-SNAPSHOT/ - Project home page: https://www.habarisoft.com/daraja_framework.html

Habari STOMP Client libraries release 2023.04 Habarisoft released new versions of its native STOMP client libraries for Delphi / Object Pascal for integration with popular open source message brokers: Habari STOMP Client for ActiveMQ 8.1 – tested with Apache ActiveMQ 5.18.0 Habari STOMP Client for Artemis 8.1 – tested with Apache ActiveMQ Artemis 2.28.0 Habari STOMP Client for OpenMQ 8.1 – tested with Eclipse OpenMQ 6.4.0 Habari STOMP Client for RabbitMQ 8.1 – tested with RabbitMQ 3.11.12 This version is mainly a maintenance release and tested with the latest message broker versions. Full release notes can be found at: https://www.habarisoft.com/release_notes.html Home page: https://www.habarisoft.com/

Yes, this would cause more work / administration. But maybe you missed the last part: "The accepted answer describes a different solution, using a 'user cert store. (...)" With this solution, no additional user would be needed. The certificate will reside in a user cert store, and is readable only for the user, inaccessible for other users.. Currenly the client is in Python: > For the client I use python while the server is done with Indy 10 using TIdTCPServer. So if there is Python support for cert stores it should be solvable. Alternatively, with Delphi, other HTTP clients may support reading from cert stores (TNetHTTPClient or others).

A client certificate should be stored in a safe place, which is not even accessible / exportable by the logged in user. Just an idea: using a cert store, the certificate may be installed with private keys marked as not exportable. Reference: How to protect private key for client cert in machine store? Is it acceptable for it to be exportable? https://security.stackexchange.com/q/260614 The accepted answer describes a different solution, using a 'user cert store'. If I understand correctly, other users would not be able to access the certificate and private key.

To clarify: you are looking for protection against malicious clients, and the server is not a concern?

TRestRequest.AddParameter('contentType', 'application/JSON', In the Screenshot cURL snippet, it is 'Content-Type: application/json'. (contentType seems to be wrong)

I have not used it in my programs, but SyncObjs.TEvent seems to be standard practice (and should be available on the Linux platform) Draft code: begin HttpServer := TMyHttpServer.Create; try HttpServer.Start; // now the server is processing requests // wait for terminate signal while MyEvent.WaitFor(MaxInt) <> wrSignaled do; // now terminate HttpServer.Stop; finally HttpServer.Free; end; end; The handler code for the http://webserver:port/stopserver URL would call MyEvent.SetEvent, and this will cause to leave the WaitFor loop.

Maybe this helps: "How can I keep a Free Pascal console application running "forever"?" https://stackoverflow.com/questions/14090697/how-can-i-keep-a-free-pascal-console-application-running-forever (it is related to the Indy TIdHTTPServer also) Basically a ReadLn could be a solution to keep the server running. But this does not answer the "or until I stop ..." part of your question and is worth a separate question. I suggest to ask the question as a new post in the Delphi-Third-Party / Indy subforum at https://en.delphipraxis.net/forum/35-indy/.

This page says for SMTP it is still accessible without modern authentication, and explains why (existing hardware which can't be updated): (Yes, the text on this page may be hard to read, as it is related three types of authentication - Basic authentication, SMTP AUTH. and modern authentication). But regarding Basic authentication and SMTP AUTH, it gets clearer by reading the the linked article "Improving Security - Together" at https://techcommunity.microsoft.com/t5/exchange-team-blog/improving-security-together/ba-p/805892 But if SMTP AUTH is not permitted (and therefore not enabled) by the organization, there are little choices. Microsoft recommends using the Graph API:

Can you be more specific, what is the exact problem? SMTP can still be used with basic auth. Modern Authentication is not required. (However, it is a security option, which can be enforced and configured by the organization)

It will not receive any feature updates, see this note on https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online Original announcement is here: https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ba-p/608055

According to https://support.microsoft.com/en-us/office/pop-imap-and-smtp-settings-8361e398-8af4-4e97-b147-6c6c4ac95353 sending e-mails via SMTP from Office 365 / Microsoft 365 should work with these settings: Server: smtp.office365.com Port: 587 Encryption: STARTTLS User name / Password: as given in https://account.microsoft.com/

In https://stackoverflow.com/questions/71993040/delphi-11-1s-firedac-and-mysql-ssl-connection-error-unknown-error-number there is one fresh comment saying "I solved the same problem today, downgrading the MySql version to 8.0.23", and one answer "I installed and uninstalled MySQL (and MySQL Workbench and MySQL Script) probably 10 times. The last install worked. I have no idea why this was necessary.". Maybe this or one of the other answers / suggestions may be helpful.

Which exact versions of the 32 OpenSSL DLLs have you tried? Are they 1.1.x or 1.0.x versions?

Next week I will go through the Sectigo CSC request again, it worked well last year. Not sure which browser - IE or Edge - I used last time. The reseller gives step-by-step instructions for Edge configuration are detailed and include many screenshots. They also offer the option to send a CSR, instead of using a browser. Maybe this is an option for those where the IE / Edge is not working as expected. I don't have experiences with K-Software, as I use a different reseller (PSW).

android.content.ServiceConnection is an interface (see https://developer.android.com/reference/android/content/ServiceConnection) Your code must (aquire or) create an instance of a class which implements this interface. If you create it in your code, you must at least implement the two non-default methods, as shown in your Java example.. type TMyServiceConnection = class (TInterfacedObject, JServiceConnection) public procedure onServiceConnected(JComponentName name, JIBinder service); procedure onServiceDisconnected(JComponentName name); ...

If this is related to EN 16931 (https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/EN+16931+compliance), maybe this code is helpful: https://github.com/LandrixSoftware/XRechnung-for-Delphi (open source, dual-licensed)

Pre-compiled DLLs for Indy are available on https://github.com/IndySockets/OpenSSL-Binaries They are not shipped with Delphi. Make sure you download and install the correct version - there are 32 and 64 bit versions of the DLLs. Which one to choose depends on your application. Installing the Indy source files on the server is not required. "Just put the DLLs in your app's installation folder."

Other way would be for example cURL, or Indy / Synapse / mORMot.

See: https://stackoverflow.com/questions/72636489/tls-1-3-for-net-4-0-under-windows-7#comment128310433_72636489

Regarding support for the latst TLS/SSL, TLS 1.3 is not included in the trunk version of Indy, but there is a pull request which adds TLS 1.3 support (see https://github.com/IndySockets/Indy/pull/299). Other options to enable 1.3 are available by attaching a commercial SSLHandler. Regarding GMail: two-factor authentication input is usually performed using the system browser. Indy's HTTP server is not involved in this step. Maybe you can be more specific what you are missing in Indy? Indy is definitely still supported, and included in all versions of Delphi and working on Windows 10/11. You may download it from GitHub: https://github.com/IndySockets/Indy p.s. regarding TLS/SSL webservers: you may place the (Indy-based) HTTP server behind a reverse proxy such as nginx or Apache HTTPD. The reverse proxy will do all the encryption work, while Indy still only uses HTTP. The reverse proxy must be configured so the clients will communicate with the proxy only. This has many advantages (think of automated certificate renewal for Let's Encrypt).

The SQL for Query2 must contain a WHERE clause to filter out only the rows for the selected employee ID. Also the GROUP BY can not not work because its SELECT clause does not use aggregate functions. GROUP BY id also makes no sense at all, as ID is the record id in the payment table.

Have you compared the requests from SoapUI with the requests sent from your code?

Thanks for clarifying, it is important to know that MQTT refers to the MQseries product from IBM and has nothing to do with “message queue“ 🙂 Some introduction posts which might be useful for others: https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/ and https://www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe/

Not sure if I understand the scenario, but messages can be configured so users will see them when back online. This is called a durable client (or durable subscription). For reference see https://stackoverflow.com/questions/34150452/receive-offline-messages-mqtt So, somehow the broker is a database, but specialized for asynchronous messaging. (Disclaimer: I dont have any 'expert knowledge' with MQTT, but its features are very similar to those of other open source message brokers I am using)