mirror of
https://github.com/NuSkooler/enigma-bbs.git
synced 2025-07-29 14:06:09 +02:00
Hopefully fix all links on doc site
This commit is contained in:
Bryan Ashby
parent
215d02b341
commit
8e8016d0fd
26 changed files with 53 additions and 53 deletions
|
|
@ -73,8 +73,8 @@ All `users` can read (see) the area, `sysops` and `co-ops` can write (upload), a
|
|||
## ACS Touch Points
|
||||
The following touch points exist in the system. Many more are planned:
|
||||
|
||||
* [Message conferences and areas](/docs/messageareas/configuring-a-message-area.md)
|
||||
* [File base areas](/docs/filebase/first-file-area.md) and [Uploads](/docs/filebase/uploads.md)
|
||||
* [Message conferences and areas](../messageareas/configuring-a-message-area.md)
|
||||
* [File base areas](../filebase/first-file-area.md) and [Uploads](../filebase/uploads.md)
|
||||
* Menus within [Menu HJSON (menu.hjson)](menu-hjson.md)
|
||||
|
||||
See the specific areas documentation for information on available ACS checks.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ ENiGMA½ configuration files such as the [system config](config-hjson.md), [menu
|
|||
## Hot-Reload
|
||||
Nearly all of ENiGMA½'s configuration can be hot-reloaded. That is, a live system can have it's configuration modified and it will be loaded in place.
|
||||
|
||||
:bulb: [Monitoring live logs](/docs/troubleshooting/monitoring-logs.md) is useful when making live changes. The system will complain if something is wrong!
|
||||
:bulb: [Monitoring live logs](.../troubleshooting/monitoring-logs.md) is useful when making live changes. The system will complain if something is wrong!
|
||||
|
||||
## Common Directives
|
||||
### Includes
|
||||
|
|
@ -74,7 +74,7 @@ Consider `actionKeys` in a menu. Often times you may show a screen and the user
|
|||
:information_source: An unresolved `@reference` will be left intact.
|
||||
|
||||
### Environment Variables
|
||||
Especially in a container environment such as [Docker](/docs/installation/docker.md), environment variable access in configuration files can become very handy. ENiGMA½ provides a flexible way to access variables using the `@environment` directive. The most basic form of `@environment:VAR_NAME` produces a string value. Additionally a `:type` suffix can be supplied to coerece the value to a particular type. Variables pointing to a comma separated list can be turned to arrays using an additional `:array` suffix.
|
||||
Especially in a container environment such as [Docker](../installation/docker.md), environment variable access in configuration files can become very handy. ENiGMA½ provides a flexible way to access variables using the `@environment` directive. The most basic form of `@environment:VAR_NAME` produces a string value. Additionally a `:type` suffix can be supplied to coerece the value to a particular type. Variables pointing to a comma separated list can be turned to arrays using an additional `:array` suffix.
|
||||
|
||||
Below is a table of the various forms:
|
||||
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@ Below is a list of various configuration sections. There are many more, but this
|
|||
* [Archivers](archivers.md): Set up external archive utilities for handling things like ZIP, ARJ, RAR, and so on.
|
||||
* [Email](email.md): System email support.
|
||||
* [Event Scheduler](event-scheduler.md): Set up events as you see fit!
|
||||
* [File Base](/docs/filebase/index.md)
|
||||
* [File Base](../filebase/index.md)
|
||||
* [File Transfer Protocols](file-transfer-protocols.md): Oldschool file transfer protocols such as X/Y/Z-Modem!
|
||||
* [Message Areas](/docs/messageareas/configuring-a-message-area.md), [Networks](/docs/messageareas/message-networks.md), [NetMail](/docs/messageareas/netmail.md), etc.
|
||||
* [Message Areas](../messageareas/configuring-a-message-area.md), [Networks](../messageareas/message-networks.md), [NetMail](../messageareas/netmail.md), etc.
|
||||
* ...and a **lot** more! Explore the docs! If you can't find something, please contact us!
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: External Support Binaries
|
|||
## External Support Binaries
|
||||
ENiGMA½ relies on various external binaries in order to perform common tasks such as processing file archives and extracting information from uploads/file imports, some legacy transfer protocols, etc.
|
||||
|
||||
:correct: Before using features such as the [File Base](/docs/filebase/index.md) or [File Transfer Protocols](/docs/configuration/file-transfer-protocols.md) it is highly recommended to install support binaries!
|
||||
:correct: Before using features such as the [File Base](../filebase/index.md) or [File Transfer Protocols](../configuration/file-transfer-protocols.md) it is highly recommended to install support binaries!
|
||||
|
||||
## Archivers
|
||||
Below is a table of pre-configured archivers. Remember that you can override settings or add new handlers! See [Archivers](archivers.md).
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ See https://hjson.org/users.html for more more editors & plugins.
|
|||
### Hot-Reload A.K.A. Live Editing
|
||||
ENiGMA½'s configuration, menu, and theme files can edited while your BBS is running. When a file is saved, it is hot-reloaded into the running system. If users are currently connected and you change a menu for example, the next reload of that menu will show the changes.
|
||||
|
||||
:information_source: See also [Configuration Files](/docs/configuration/config-files.md)
|
||||
:information_source: See also [Configuration Files](../configuration/config-files.md)
|
||||
|
||||
### CaSe SeNsiTiVE
|
||||
Configuration keys are **case sensitive**. That means if a configuration key is `boardName` for example, `boardname`, or `BOARDNAME` **will not work**.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ showSomeArt: {
|
|||
config: { pause: true }
|
||||
}
|
||||
```
|
||||
As you can see a menu can be very simple.
|
||||
As you can see a menu can be very simple.
|
||||
|
||||
:information_source: Remember that the top level menu may include additional files using the `includes` directive. See [Configuration Files](config-files.md) for more information on this.
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ Below is a table of **common** menu entry members. These members apply to most e
|
|||
| Item | Description |
|
||||
|--------|--------------|
|
||||
| `desc` | A friendly description that can be found in places such as "Who's Online" or wherever the `%MD` MCI code is used. |
|
||||
| `art` | An art file *spec*. See [General Art Information](/docs/art/general.md). |
|
||||
| `art` | An art file *spec*. See [General Art Information](../art/general.md). |
|
||||
| `next` | Specifies the next menu entry to go to next. Can be explicit or an array of possibilities dependent on ACS. See **Flow Control** in the **ACS Checks** section below. If `next` is not supplied, the next menu is this menus parent. Note that special built in methods such as `@systemMethod:logoff` can also be utilized here. |
|
||||
| `prompt` | Specifies a prompt, by name, to use along with this menu. Prompts are configured in the `prompts` section. See **Prompts** for more information. |
|
||||
| `submit` | Defines a submit handler when using `prompt`.
|
||||
|
|
@ -41,7 +41,7 @@ Below is a table of **common** menu entry members. These members apply to most e
|
|||
### Menu Modules
|
||||
A given menu entry is backed by a *menu module*. That is, the code behind it. Menus are considered "standard" if the `module` member is not specified (and therefore backed by `core/standard_menu.js`).
|
||||
|
||||
See [Menu Modules](/docs/modding/menu-modules.md) for more information.
|
||||
See [Menu Modules](../modding/menu-modules.md) for more information.
|
||||
|
||||
### Config Block
|
||||
The `config` block for a menu entry can contain common members as well as a per-module (when `module` is used) settings.
|
||||
|
|
@ -51,8 +51,8 @@ The `config` block for a menu entry can contain common members as well as a per-
|
|||
| `cls` | If `true` the screen will be cleared before showing this menu. |
|
||||
| `pause` | If `true` a pause will occur after showing this menu. Useful for simple menus such as displaying art or status screens. |
|
||||
| `nextTimeout` | Sets the number of **milliseconds** before the system will automatically advanced to the `next` menu. |
|
||||
| `baudRate` | See baud rate information in [General Art Information](/docs/art/general.md). |
|
||||
| `font` | Sets a SyncTERM style font to use when displaying this menus `art`. See font listing in [General Art Information](/docs/art/general.md). |
|
||||
| `baudRate` | See baud rate information in [General Art Information](../art/general.md). |
|
||||
| `font` | Sets a SyncTERM style font to use when displaying this menus `art`. See font listing in [General Art Information](../art/general.md). |
|
||||
| `menuFlags` | An array of menu flag(s) controlling menu behavior. See **Menu Flags** below.
|
||||
|
||||
#### Menu Flags
|
||||
|
|
@ -70,7 +70,7 @@ ENiGMA½ uses a concept of *forms* in menus. A form is a collection of associate
|
|||
|
||||
Menus may also support more than one layout type by using a *MCI key*. A MCI key is a alpha-numerically sorted key made from 1:n MCI codes. This lets the system choose the appropriate set of form(s) based on theme or random art. An example of this may be a matrix menu: Perhaps one style of your matrix uses a vertical light bar (`VM` key) while another uses a horizontal (`HM` key). The system can discover the correct form to use by matching MCI codes found in the art to that of the available forms defined in `menu.hjson`.
|
||||
|
||||
For more information on views and associated MCI codes, see [MCI Codes](/docs/art/mci.md).
|
||||
For more information on views and associated MCI codes, see [MCI Codes](../art/mci.md).
|
||||
|
||||
## Submit Handlers
|
||||
When a form is submitted, it's data is matched against a *submit handler*. When a match is found, it's *action* is performed.
|
||||
|
|
@ -135,7 +135,7 @@ telnetConnected: {
|
|||
```
|
||||
|
||||
The above entry `telnetConnected` is set as the Telnet server's first menu entry (set by `firstMenu` in the Telnet server's config). The entry sets up a few things:
|
||||
* A `art` spec of `CONNECT`. (See [General Art Information](/docs/art/general.md)).
|
||||
* A `art` spec of `CONNECT`. (See [General Art Information](../art/general.md)).
|
||||
* A `next` entry up the next menu, by name, in the stack (`matrix`) that we'll go to after `telnetConnected`.
|
||||
* An `config` block containing a single `nextTimeout` field telling the system to proceed to the `next` (`matrix`) entry automatically after 1500ms.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ Unlike in the golden era of BBSing, modern Internet-connected systems are prone
|
|||
|
||||
## Two-Factor Authentication via One-Time Password
|
||||
Enabling Two-Factor Authentication via One-Time-Password (2FA/OTP) on an account adds an extra layer of security ("_something a user has_") in addition to their password ("_something a user knows_"). Providing 2FA/OTP to your users has some prerequisites:
|
||||
* [A configured email gateway](/docs/configuration/email.md) such that the system can send out emails.
|
||||
* One or more secure servers enabled such as [SSH](/docs/servers/ssh.md) or secure [WebSockets](/docs/servers/websocket.md) (that is, WebSockets over a secure connection such as TLS).
|
||||
* The [web server](/docs/servers/web-server.md) enabled and exposed over TLS (HTTPS).
|
||||
* [A configured email gateway](../configuration/email.md) such that the system can send out emails.
|
||||
* One or more secure servers enabled such as [SSH](../servers/ssh.md) or secure [WebSockets](../servers/websocket.md) (that is, WebSockets over a secure connection such as TLS).
|
||||
* The [web server](../servers/web-server.md) enabled and exposed over TLS (HTTPS).
|
||||
|
||||
:information_source: For WebSockets and the web server, ENiGMA½ _may_ listen on insecure channels if behind a secure web proxy.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ Due to the nature of 2FA/OTP, even if enabled on your system, users must opt-in
|
|||
|
||||
:warning: Serving 2FA/OTP registration links over insecure (HTTP) can expose secrets intended for the user and is **highly** discouraged!
|
||||
|
||||
:memo: +ops can also manually enable or disable 2FA/OTP for a user using [oputil](/docs/admin/oputil.md), but this is generally discouraged.
|
||||
:memo: +ops can also manually enable or disable 2FA/OTP for a user using [oputil](../admin/oputil.md), but this is generally discouraged.
|
||||
|
||||
#### Recovery
|
||||
In the situation that a user loses their 2FA/OTP device (such as a lost phone with Google Auth), there are some options:
|
||||
|
|
@ -36,11 +36,11 @@ In the situation that a user loses their 2FA/OTP device (such as a lost phone wi
|
|||
:warning: There is no way for a user to disable 2FA/OTP without first fully logging in! This is by design as a security measure.
|
||||
|
||||
### ACS Checks
|
||||
Various places throughout the system that implement [ACS](/docs/configuration/acs.md) can make 2FA specific checks:
|
||||
Various places throughout the system that implement [ACS](../configuration/acs.md) can make 2FA specific checks:
|
||||
* `AR#`: Current users **required** authentication factor. `AR2` for example means 2FA/OTP is required for this user.
|
||||
* `AF#`: Current users **active** authentication factor. `AF2` means the user is authenticated with some sort of 2FA (such as One-Time-Password).
|
||||
|
||||
See [ACS](/docs/configuration/acs.md) for more information.
|
||||
See [ACS](../configuration/acs.md) for more information.
|
||||
|
||||
#### Example
|
||||
The following example illustrates using an `AR` ACS check to require applicable users to go through an additional 2FA/OTP process during login:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue