Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions Docs/src/content/docs/design/client-tls.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
title: Client TLS
description: Information about when and why TLS & HTTPS are used for communicating with the Client and Studio.
---

Transport Layer Security (TLS) is a cryptographic protocol that provides secure communication over a network. It is commonly used to encrypt data transmitted between clients and servers, ensuring confidentiality and integrity of the data. In the modern web, TLS is used as a part of HTTPS, and is essential for protecting user data and allowing the user to verify the identity of the server they are communicating with.

In the context of Mercury, it would be best to use TLS and HTTPS for all communication between the Site and the Client and Studio. However, this is often not possible due to technical limitations of the Client and Studio. Due to this, Mercury Core takes a flexible approach to allow TLS to be used as much as possible, while minimising risk of security issues when it cannot be used.

## TLS versions

A table of various TLS versions is provided below.

Version | Year released | Status
-- | -- | --
1.0 | 1999 | Deprecated in 2021
1.1 | 2006 | Deprecated in 2021
1.2 | 2008 | Widely supported, no plans for deprecation
1.3 | 2018 | Widely supported, latest version

Later versions of TLS provide improved security and performance. The [Caddy](/install/caddy) web server used by Mercury Core does not support deprecated versions of TLS (as of Caddy 2, see Caddy issues [#2819](https://github.com/caddyserver/caddy/issues/2819) and [#3667](https://github.com/caddyserver/caddy/issues/3667) for more info). However, some older Clients may not support TLS 1.2 or later, so it may be necessary to introduce a different external proxy server or load balancer that supports older TLS versions if support for these Clients is desired.

## Unencrypted subdomain

By default, Mercury Core is configured to host the Site on the root domain (eg. `example.com`), which is always encrypted with HTTPS, and an unencrypted subdomain (eg. `www.example.com`) is used only for communication with the Client and Studio. This allows the Site to always be accessed securely by users through their web browsers, while still allowing systems that don't support TLS to communicate with the unencrypted subdomain.

The unencrypted subdomain should never be used for Site access from a web browser. This is why a separate subdomain is the recommended approach. Under proper configuration of Mercury Core, any user attempting to access the Site through an unencrypted connection will not be able to submit any information in forms to minimise the risk of sensitive data being intercepted.
20 changes: 20 additions & 0 deletions Docs/src/content/docs/design/mercury3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
title: Mercury 3 & Mercury Core
description: An overview on the relationship between Mercury 3 and Mercury Core.
---

Mercury 3 is a revival platform using a hosted version of Mercury Core as its source code. This page provides an overview of the relationship between Mercury 3 and Mercury Core.

## Development of Mercury 2

As explained in the [History](/history) page, the source code of Mercury 2 continued undergoing modification after it was shut down in June 2024, being released as Mercury Core in September 2024. As such, Mercury 2 is not considered to be based on Mercury Core.

Mercury 2 changed a significant amount during its 2 years of development. Many core pieces of the codebase were modified or rewritten, services were changed, and libraries used (many of which were in beta or early development at the time) were updated or replaced. As such, while Mercury Core shows clear resemblance with Mercury 2[^1] in 2024, the resemblance with a version of Mercury 2 from 2022 or 2023 is less clear.

## Development of Mercury 3

The development process of Mercury 3 has been very different to that of Mercury 2.

todo

[^1]: These changes can be viewed in full, with code change history throughout the entirety of Mercury 2, in Mercury Core's [commit history](https://github.com/tp-link-extender/MercuryCore/commits/).
28 changes: 25 additions & 3 deletions Docs/src/content/docs/guides/config.mdoc
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,8 @@ This guide provides information on the configuration file for Mercury Core, loca
While the configuration file aims to give control over as many options as possible in a pragmatic manner, the most effective way to tweak Mercury Core and other components of the Mercury suite will always be to modify their source code directly.
{% /aside %}

Properties are grouped in ways that are intended to be intuitive, though other than this there are no strict rules on how they are organised. These groups, the names of the properties, and their default values, are all subject to change, and may be rearranged, renamed, or removed in future updates. The order of properties listed here is in accordance with how they appear in the reference configuration file, though they can be rearranged in any way as required.

## Properties

### Top-level
Expand All @@ -19,11 +21,13 @@ This is the name of the project, used across the codebase wherever the project n

#### Domain

The domain that the site will be primarily hosted from, without the URL scheme. For example, if the site is hosted at `https://example.com`, then this should be set to `example.com`. This is used in various places across the codebase where the domain needs to be referenced, including in constructing Client scripts & emails and substituting parts of existing URLs in XML-based assets.
The domain that the Site will be primarily hosted from, without the URL scheme. For example, if the Site is hosted at `https://example.com`, then this should be set to `example.com`. This is used in various places across the codebase where the domain needs to be referenced, including in constructing Client scripts & emails and substituting parts of existing URLs in XML-based assets.

#### DatabaseDomain
#### DomainInsecure

The domain name of the database server, without the URL scheme. This is used when setting up the Site's database connection. This domain is not accessed securely by default, so it's recommended to keep it on a local network or on the same machine as the Site. Make sure to include the port if necessary.
The domain that the Site will be hosted on when accessed insecurely, without the URL scheme. This is used for requests that do not or cannot support HTTPS. By default, this is the Domain property with a `www.` subdomain added.

This domain should not be used to access the Site. More information is given in the [Client TLS](/design/client-tls) section of the documentation.

#### RCCServiceProxyURL

Expand Down Expand Up @@ -51,4 +55,22 @@ The symbol to use when displaying currency values across the site. This is used

An array that contains the optional pages for the site, with a string value for each name: Statistics, Groups, and Forum. If a page is removed from this array, it will not be accessible on the site, returning a 404 Not Found error, and any links to it will be removed from the UI.

### Database

#### Database – AutoStart

Whether to automatically start the database server when starting the Site. Requires that [SurrealDB](/install/surrealdb) is installed and available on the command line or in your system's PATH as `surreal`.

This is recommended to be enabled in all cases except when debugging database issues, or when managing the database server separately from the Site, surch as when using a container manager.

#### Database – Domain

The domain name of the database server, without the URL scheme. This is used when setting up the Site's database connection. This domain is not accessed securely by default, so it's recommended to keep it on a local network or on the same machine as the Site. Make sure to include the port if necessary.

### Economy

#### Economy – AutoStart

Whether to automatically start the Economy service when starting the Site. This is recommended to be enabled in all cases except when debugging Economy service issues, or when managing the Economy service separately from the Site, such as when using a container manager.

### todo
Loading
Loading