We have migrated from modified version of YaBB 2.7.00 to phpBB! We have migrated, because YaBB forum software is not actively maintained anymore and our previous forum used tables for layout (which is not recommended from SEO perspective). We had to modify YaBB due to its security vulnerabilities. The new phpBB forum should be fairly secure.

We have started the migration in February 10th, 2024, and we have finished the forum in February 14th, 2024.

Our forum is dedicated to SVR.JS web server and webmaster activities.

You can visit and/or register on the forum at https://forum.svrjs.org. You can also visit it on Tapatalk (search forum.svrjs.org).

Read More

SVR.JS 3.4.42 was the last supported release from SVR.JS 3.4.x LTS line. and also the last SVR.JS release to ever support Node.JS 8.x and 9.x. There will be no futher SVR.JS updates for such old Node.JS versions.

Why SVR.JS ended support for SVR.JS 3.4.x LTS?

SVR.JS 3.4.x was one of the last web server software to support Node.JS 8.x and 9.x. OpenJS Foundation itself ended official support for Node.JS 8.x in December 2019 and Node.JS 9.x in June 2018. Unsupported Node.JS versions receive no security updates, have known vulnerabilites, and can be dangerous to use, which makes it difficult to maintain SVR.JS on those versions. Earlier, we had set the EOL date to Feburary 2024.

Will switching to a different Node.JS-based server software keep me protected?

No. Most active Node.JS-based server software (such as http-server or server.js) have already ended support for Node.JS 8.x and 9.x.

Read More

SVR.JS had just dropped all remnants of “DorianTech” from its development branch after 5 years since SVR.JS was created. It will be soon dropped from future SVR.JS release versions and official SVR.JS mods.

A brief history of SVR.JS

SVR.JS was created in 2018 as “DorianTech Node.JS Server” to serve single website. Since then, SVR.JS is constantly improving. SVR.JS 1.x introduced directory listings, while SVR.JS 2.x introduced multi-clustering, .tar.gz SVR.JS mods, and server-side JavaScript. Until its development was suspended in 2020.

But SVR.JS 2.x had a lot of problems, like XSS and path traversal security vulnerabilities, “unexcepted execptions”, malformed URL crashes, no support for SNI, HTTP compression (it was broken) and URL rewriting. What’s worse, SVR.JS has no documentation!

SVR.JS “woke up” in 2023, when there was a need for another website.
SVR.JS 2.x problems were fixed in SVR.JS 3.x, although it still retained the “Welcome to DorianTech SVR.JS Server” message from SVR.JS 2.x. Logo and directory listing icons were also redesigned. The documentation has been written.

Read More

SQL injection (SQLi) attacks may destroy your database. These attacks are one of the most common attacks on websites (it is in the OWASP Top Ten). This attack relies on injecting code into SQL database queries through the user input.

WARNING: We’re not responsible for damage caused by SQL injection! Malicious hacking is a computer crime and you may face legal consequences! This post is meant to gain awareness about SQL injection and give a way to prevent those vulnerabilities.

The impact of SQL injection

SQL injection attacks may result in unauthorized access to sensitive data, such as:

• Passwords
• Credit card information
• Personal user information
• Information normally hidden from website users

Read More

We have discovered more security vulnerabilites, this time in SVR.JS itself. We have patched SVR.JS, but we recommend to upgrade your SVR.JS web server to patched versions immediately.

Patched versions:

• SVR.JS 3.9.2 and newer
• SVR.JS 3.4.30 LTS and newer

Unpatched versions didn’t properly sanitize URLs for SVR.JS mods and server-side JavaScript, leaving them vulnerable. You can view our security advisory.

UPDATE: We have discovered and mitigated even more security vulnerabilites in SVR.JS itself. We recommend to upgrade your SVR.JS web server to patched versions immediately.

Read More

Bun - a Node.JS-compatible JavaScript runtime (using JavaScriptCore), package manager, bundler, test runner and all-in-one toolkit has finally a production-ready version - Bun 1.0!

We did get SVR.JS working in Bun, beginning with SVR.JS 3.0.0. But Bun changed fast, and so older SVR.JS versions won’t work properly with newest versions of Bun. We have tested Bun 1.0 (it introduced native IPC not present in Bun 0.x), patched SVR.JS and released SVR.JS 3.9.4 and SVR.JS 3.4.32 LTS (older versions displayed TypeErrors with Bun 1.0).

Bun support is still experimental though, so you may run into problems with SVR.JS startup (“There was an unknown error with the server.“ errors; master will shut down but worker will be active) or see “There was a problem when handling SVR.JS worker! (from master process side)“ warnings, because Bun doesn’t support native clustering yet (SVR.JS shims missing cluster module; the shim may break with newer versions of Bun making SVR.JS reliability suffer).

If you run into issues running SVR.JS on Bun 1.0, try using Bun 0.8.1 (latest developement version; it works with clustered SVR.JS and it’s shim) or Node.JS (SVR.JS is designed for it).

You may also create this startup script for SVR.JS running on Bun 1.0 like this (multiple clustering will not work on SVR.JS running on Bun 1.0, so SVR.JS will fail to start new worker in case the previous ones hung up, but SVR.JS will at least start new worker in case if all of the workers had crashed):

Read More

We have discovered security vulnerabilites in those SVR.JS mods. Fortunately we have patched those mods. But it’s recommended to upgrade these mods immediately.

Patched versions:

• RedBrick 2.3.3 and newer
• reverse-proxy-mod 1.0.4 and newer
• OrangeCircle 1.0.2 and newer
• YellowSquare 1.0.1 and newer

Unpatched versions have various configuration file and source code leakage vulnerabilities. You can view our security advisory.

UPDATE: We discovered this vulnerability: “An attacker could hack the upstream server, replace the web server or application with one that sends an invalid HTTP response code, and make a request to the hacked server through the reverse proxy to crash the reverse proxy server”. The vulnerability is patched in reverse-proxy-mod 1.1.2 and newer.

Read More

We have recently added support for PHP-CGI and SCGI. We have implemented JSGI in SVR.JS through new YellowSquare mod. We have more specifically implemented JSGI Level 0/A Draft 2 Proposal (aka JSGI 0.3).
JSGI (JavaScript Gateway Interface) is an interface between JavaScript web applications and web servers. It is inspired by Rack by Ruby and WSGI by Python. JSGI is included in and further developed by the CommonJS project.
Since SVR.JS is written in JavaScript, we could easily implement JSGI.
This blog post will instruct you, how to set up JSGI web applications on SVR.JS.

Setting up JSGI

First of all, download and install SVR.JS web server. You can also use create-svrjs-server tool or SVR.JS installer to install SVR.JS.

After setting up SVR.JS, download and install YellowSquare to mods directory.

JSGI web applications in YellowSquare have .jsgi or .jsgi.js extensions and reside in jsgi-bin directory in the web root.

Read More

We have previously made SVR.JS run PHP-CGI and WordPress. Now SVR.JS - a web server software running on Node.JS can connect to SCGI (Simple Common Gateway Interface) servers.
We have developed a new mod to do that, OrangeCircle (SCGI client written in JavaScript running on SVR.JS).
SCGI (Simple Common Gateway Interface) is a protocol to interface web applications with HTTP servers, which is an alternative to CGI. It is similar to FastCGI, but it is easier to parse and implement. SCGI doesn’t have interpreter invoking overhead, unlike CGI.
This post will instruct you, how to set up SCGI web applications on SVR.JS.

Setting up SCGI on server-side

First of all, download and install SVR.JS web server. You can also use create-svrjs-server tool or SVR.JS installer to install SVR.JS.

After setting up SVR.JS, download and install OrangeCircle to mods directory.

After installing OrangeCircle SCGI client, create orangecircle-config.json file in SVR.JS installation directory, and configure it like this:

Read More

SVR.JS - a web server software running on Node.JS can now run PHP through PHP-CGI and RedBrick mod.
Because SVR.JS can run PHP, SVR.JS can also run WordPress. Keep in mind, that it comes with CGI overhead. This post will instruct you, how to set up PHP and WordPress on SVR.JS.

Installing PHP

First, download and install SVR.JS per documentation. You can also use create-svrjs-server tool to do that.

Since neither SVR.JS nor Node.JS has native PHP library, we’re using and installing PHP-CGI. To do this, first download and install RedBrick (2.3.2 or newer) into mods directory. RedBrick is a CGI runtime written in JavaScript running on SVR.JS.

After we have installed CGI runtime, we’re installing PHP-CGI. You can download PHP manually, however in many GNU/Linux distributions it is available in package manager. For Debian/Ubuntu you can run sudo apt install php-cgi. For Red Hat/CentOS/Fedora you can run sudo yum install php-cgi or sudo dnf install php-cgi. For Arch/Manjaro you can run sudo pacman -S php-cgi.

Read More