mirrors/hedgedoc
1
0
Fork 0
mirror of https://github.com/hedgedoc/hedgedoc.git synced 2025-05-22 19:25:18 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

docs: run lint:fix

Browse source 
Signed-off-by: Philip Molares <philip.molares@udo.edu>
This commit is contained in:
Philip Molares 2023-07-06 02:45:32 +02:00
parent 366515e760
commit 50d4959e0a
21 changed files with 526 additions and 360 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/content/dev/auth/ldap.md
View file

@ -1,6 +1,7 @@
# LDAP
LDAP authentication can be tested with the [`test-openldap`](https://github.com/rroemhild/docker-test-openldap) docker image from [rroemhild](https://github.com/rroemhild).
LDAP authentication can be tested with the [`test-openldap`][docker-image]
docker image from [rroemhild][rroemhild].
Simply run
@ -10,7 +11,7 @@ docker run --rm -p 10389:10389 -p 10636:10636 rroemhild/test-openldap
and add the following to the `.env` file before starting the backend.
```
```dotenv
HD_AUTH_LDAPS="FUTURAMA"
HD_AUTH_LDAP_FUTURAMA_PROVIDER_NAME="Futurama LDAP"
HD_AUTH_LDAP_FUTURAMA_URL="ldap://localhost:10389"
@ -32,3 +33,5 @@ You should then be able to log in with either of these logins (`username` : `pas
- `bender` : `bender`
- `amy` : `amy`
[docker-image]: https://github.com/rroemhild/docker-test-openldap
[rroemhild]: https://github.com/rroemhild

30
docs/content/dev/design_docs/api_auth.md
View file

@ -6,7 +6,7 @@ feature. It is not a user guide and may or may not be fully implemented.
## Public API
All requests to the public API require authentication using a [bearer token](https://datatracker.ietf.org/doc/html/rfc6750).
All requests to the public API require authentication using a [bearer token][bearer-token].
This token can be generated using the profile page in the frontend
(which in turn uses the private API to generate the token).
@ -14,27 +14,28 @@ This token can be generated using the profile page in the frontend
### Token generation
When a new token is requested via the private API, the backend generates a 64 bytes-long secret of
cryptographically secure data and returns it as a base64url-encoded string, along with an identifier.
That string can then be used by clients as a bearer token.
cryptographically secure data and returns it as a base64url-encoded string,
along with an identifier. That string can then be used by clients as a bearer token.
A SHA-512 hash of the secret is stored in the database. To validate tokens, the backend computes the hash of the provided
secret and checks it against the stored hash for the provided identifier.
A SHA-512 hash of the secret is stored in the database. To validate tokens, the backend computes
the hash of the providedsecret and checks it against the stored hash for the provided identifier.
#### Choosing a hash function
Unfortunately, there does not seem to be any explicit documentation about our exact use-case.
Most docs describe classic password-saving scenarios and recommend bcrypt, scrypt or argon2.
These hashing functions are slow to stop brute-force or dictionary attacks, which would expose the original,
user-provided password, that may have been reused across multiple services.
These hashing functions are slow to stop brute-force or dictionary attacks, which would expose
the original, user-provided password, that may have been reused across multiple services.
We have a very different scenario:
Our API tokens are 64 bytes of cryptographically strong pseudorandom data.
Brute-force or dictionary attacks are therefore virtually impossible, and tokens are not reused across multiple services.
Brute-force or dictionary attacks are therefore virtually impossible, and tokens are not
reused across multiple services.
We therefore need to only guard against one scenario:
An attacker gains read-only access to the database. Saving only hashes in the database prevents the attacker
from authenticating themselves as a user. The hash-function does not need to be very slow,
as the randomness of the original token prevents inverting the hash. The function actually needs to be reasonably fast,
as the hash must be computed on every request to the public API.
An attacker gains read-only access to the database. Saving only hashes in the database prevents the
attacker from authenticating themselves as a user. The hash-function does not need to be very slow,
as the randomness of the original token prevents inverting the hash. The function actually needs to
be reasonably fast, as the hash must be computed on every request to the public API.
SHA-512 (or alternatively SHA3) fits this use-case.
## Private API
@ -57,4 +58,7 @@ using one of the supported authentication methods:
- Google
The `SessionGuard`, which is added to each (appropriate) controller method of the private API,
checks if the provided session is still valid and provides the controller method with the correct user.
checks if the provided session is still valid and provides the controller method
with the correct user.
[bearer-token]: https://datatracker.ietf.org/doc/html/rfc6750

37
docs/content/dev/design_docs/config.md
View file

@ -6,7 +6,8 @@
The configuration of HedgeDoc 2 is handled entirely by environment variables.
Most of these variables are prefixed with `HD_` (for HedgeDoc).
NestJS - the framework we use - is reading the variables from the environment and also from the `.env` file in the root of the project.
NestJS - the framework we use - is reading the variables from the environment and also from
the `.env` file in the root of the project.
## How the config code works
@ -47,19 +48,25 @@ Each of those files (except `auth.config.ts` which is discussed later) consists
### Interface
The interface just describes which options the configuration has and how the rest of HedgeDoc can use them. All enums that are used in here are put in their own files with the extension `.enum.ts`.
The interface just describes which options the configuration has and how the rest of HedgeDoc can
use them. All enums that are used in here are put in their own files with the extension `.enum.ts`.
### Joi Schema
We use [Joi][joi] to validate each provided configuration to make sure the configuration of the user is sound and provides helpful error messages otherwise.
We use [Joi][joi] to validate each provided configuration to make sure the configuration of the user
is sound and provides helpful error messages otherwise.
The most important part here is that each value ends with `.label()`. This names the environment variable that corresponds to each config option. It's very important that each config option is assigned the correct label to have meaningful error messages that benefit the user.
The most important part here is that each value ends with `.label()`. This names the
environment variable that corresponds to each config option. It's very important that each config
option is assigned the correct label to have meaningful error messages that benefit the user.
Everything else about how Joi works and how you should write schemas can be read in [their documentation][joi-doc].
Everything else about how Joi works and how you should write schemas can
be read in [their documentation][joi-doc].
### A default export
The default exports are used by NestJS to provide the values to the rest of the application. We mostly do four things here:
The default exports are used by NestJS to provide the values to the rest of the application.
We mostly do four things here:
1. Populate the config interface with environment variables, creating the config object.
2. Validate the config object against the Joi schema.
@ -68,15 +75,25 @@ The default exports are used by NestJS to provide the values to the rest of the
## How `auth.config.ts` works
Because it's possible to configure some authentication providers multiple times (e.g. multiple LDAPs or GitLabs), we use user defined environment variable names. With the user defined names it's not possible to put the correct labels in the schema or build the config objects as we do in every other file.
Because it's possible to configure some authentication providers multiple times
(e.g. multiple LDAPs or GitLabs), we use user defined environment variable names.
With the user defined names it's not possible to put the correct labels in the schema
or build the config objects as we do in every other file.
Therefore, we have two big extra steps in the default export:
1. To populate the config object we have some code at the top of the default export to gather all configured variables into arrays.
2. The error messages are piped into the util method `replaceAuthErrorsWithEnvironmentVariables`. This replaces the error messages of the form `gitlab[0].providerName` with `HD_AUTH_GITLAB_<nameOfFirstGitlab>_PROVIDER_NAME`. For this the util function gets the error, the name of the config option (e.g `'gitlab'`), the approriate prefix (e.g. `'HD_AUTH_GITLAB_'`), and an array of the user defined names.
1. To populate the config object we have some code at the top of the default export to gather all
configured variables into arrays.
2. The error messages are piped into the util method `replaceAuthErrorsWithEnvironmentVariables`.
This replaces the error messages of the form `gitlab[0].providerName`
with `HD_AUTH_GITLAB_<nameOfFirstGitlab>_PROVIDER_NAME`. For this the util function gets
the error, the name of the config option (e.g `'gitlab'`), the approriate prefix
(e.g. `'HD_AUTH_GITLAB_'`), and an array of the user defined names.
## Mocks
Some config files also have a `.mock.ts` file which defines the configuration for the e2e tests. Those files just contain the default export and return the mock config object.
Some config files also have a `.mock.ts` file which defines the configuration for the e2e tests.
Those files just contain the default export and return the mock config object.
[csp]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
[hsts]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

13
docs/content/dev/design_docs/events.md
View file

@ -1,17 +1,18 @@
# Events
!!! info "Design Document"
This is a design document, explaining the design and vision for a HedgeDoc 2
feature. It is not a user guide and may or may not be fully implemented.
This is a design document, explaining the design and vision for a HedgeDoc 2
feature. It is not a user guide and may or may not be fully implemented.
In HedgeDoc 2, we use an event system based on [EventEmitter2][eventemitter2].
It's used to reduce circular dependencies between different services and inform these services about changes.
It's used to reduce circular dependencies between different services and inform these services
about changes.
HedgeDoc's system is basically [the system NestJS offers][nestjs/eventemitter].
The config for the `EventEmitterModule` is stored in `events.ts` and exported as `eventModuleConfig`.
In the same file enums for the event keys are defined. Each of these events is expected to be sent with an additional value.
The config for the `EventEmitterModule` is stored in `events.ts` and
exported as `eventModuleConfig`. In the same file enums for the event keys are defined.
Each of these events is expected to be sent with an additional value.
In the enum definition a comment should tell you what exactly this value should be.
[eventemitter2]: https://github.com/EventEmitter2/EventEmitter2
[nestjs/eventemitter]: https://docs.nestjs.com/techniques/events

77
docs/content/dev/design_docs/notes.md
View file

@ -7,7 +7,7 @@
Each note in HedgeDoc 2 contains the following information:
- publicId (`b604x5885k9k01bq7tsmawvnp0`)
- a list of aliases (`[hedgedoc-2, hedgedoc-next]`)
- a list of aliases (`[HedgeDoc-2, HedgeDoc-next]`)
- groupPermissions
- userPermissions
- viewCount (`0`)
@ -20,61 +20,88 @@ Each note in HedgeDoc 2 contains the following information:
- tags (`[features, cool, update]`)
- version
The `publicId` is the default possibility of identifying a note. It will be a randomly generated 128-bit value encoded with [base32-encode](https://www.npmjs.com/package/base32-encode) using the crockford variant and converted to lowercase. This variant of base32 is used, because that results in ids that only use one case of alpha-numeric characters and other url safe characters. We convert the id to lowercase, because we want to minimize case confusion.
The `publicId` is the default possibility of identifying a note. It will be a randomly generated
128-bit value encoded with [base32-encode][base32-encode] using the crockford variant and converted
to lowercase. This variant of base32 is used, because that results in ids that only use one case of
alpha-numeric characters and other url safe characters. We convert the id to lowercase, because we
want to minimize case confusion.
`aliases` are the other way of identifying a note. There can be any number of them, and the owner of the note is able to add or remove them. All aliases are just strings (especially to accommodate the old identifier from HedgeDoc 1 [see below](#conversion-of-hedgedoc-1-notes)), but new aliases added with HedgeDoc 2 will only allow characters matching this regex: `[a-z0-9\-_]`. This is done to once again prevent case confusion. One of the aliases can be set as the primary alias, which will be used as the identifier for the history entry.
`aliases` are the other way of identifying a note. There can be any number of them, and the owner
of the note is able to add or remove them. All aliases are just strings (especially to accommodate
the old identifier from HedgeDoc 1 [see below](#conversion-of-hedgedoc-1-notes)), but new aliases
added with HedgeDoc 2 will only allow characters matching this regex: `[a-z0-9\-_]`. This is done to
once again prevent case confusion. One of the aliases can be set as the primary alias, which will be
used as the identifier for the history entry.
`groupPermissions` and `userPermissions` each hold a list of the appropriate permissions.
Each permission holds a reference to a note and a user/group and specify what the user/group is allowed to do.
Each permission is additive, that means a user that has only the right to read a note via a group, but the right to write via a different group or directly for his user, is able to write in the note.
Each permission holds a reference to a note and a user/group and specify what the user/group
is allowed to do.
Each permission is additive, that means a user that has only the right to read a note via a group,
but the right to write via a different group or directly for his user, is able to write in the note.
The `viewCount` is a simple counter that holds how often the read-only view of the note in question was requested.
The `viewCount` is a simple counter that holds how often the read-only view of the note in question
was requested.
`owner` is the user that created the note or later got ownership of the note. The current owner is able to change the owner of the note to someone else. The owner of a note is the only person that can perform the following actions:
`owner` is the user that created the note or later got ownership of the note. The current owner is
able to change the owner of the note to someone else. The owner of a note is the only person that
can perform the following actions:
- delete the note
- modify `aliases`
- remove all `revisions`
The `revisions` hold all revisions of the note. These are the changes to the note content and by whom they were performed.
The `revisions` hold all revisions of the note. These are the changes to the note content and by
whom they were performed.
The `authorColors` each specify for the tuple user and note which color should be used to highlight them.
The `authorColors` each specify for the tuple user and note which color should be used
to highlight them.
The `historyEntries` hold the history entries this note is referenced in. They are mainly here for the purpose of deleting the history entries on note deletion.
The `historyEntries` hold the history entries this note is referenced in. They are mainly here
for the purpose of deleting the history entries on note deletion.
`description`, `tags` and `title` are each information specified in the [frontmatter][frontmatter] of the note. They are extracted and saved in the database to allow the history page to show them and do a search for tags without having to do a full-text search or having to parse the tags of each note on search.
`description`, `tags` and `title` are each information specified in the [frontmatter][frontmatter]
of the note. They are extracted and saved in the database to allow the history page to show them and
do a search for tags without having to do a full-text search or having to parse the tags of
each note on search.
While `description` and `tags` are only specified by the [frontmatter][frontmatter], the title is
- the content of the *title* field of the [frontmatter][frontmatter] of the note
- **OR** the content of the *title* field in the *opengraph* field of the [frontmatter][frontmatter] of the note
- **OR** the first level 1 heading of the note
- **OR** the content of the *title* field in the *opengraph* field of the [frontmatter][frontmatter]
of the note
- **OR** the first level 1 heading of the note
which ever of these is the first to not be unspecified.
All mentioned fields are extracted from the note content by the backend on save or update.
`version` specifies if a note is an old HedgeDoc 1 note, or a new HedgeDoc 2 note. This is mainly used to redirect old notes form <https://md.example.org/noteid> to <https://md.example.org/n/noteid>.
`version` specifies if a note is an old HedgeDoc 1 note, or a new HedgeDoc 2 note.
This is mainly used to redirect old notes form <https://md.example.org/noteid>
to <https://md.example.org/n/noteid>.
## Deleting Notes
- The owner of a note may delete it.
- By default, this also removes all revisions and all files that were uploaded to that note.
- The owner may choose to skip deleting associated uploads, leaving them without a note.
- The frontend should show a list of all uploads that will be affected
and provide a method of skipping deletion.
- By default, this also removes all revisions and all files that were uploaded to that note.
- The owner may choose to skip deleting associated uploads, leaving them without a note.
- The frontend should show a list of all uploads that will be affected
and provide a method of skipping deletion.
- The owner of a note may delete all revisions. This effectively purges the edit
history of a note.
## Conversion of HedgeDoc 1 notes
First we want to define some terms of the HedgeDoc 1 notes:
- **noteId**: This refers to the auto-generated id for new notes. (https://demo.hedgedoc.org/Q_Iz5T_lQWGYxne0sbMtwg)
- **noteId**: This refers to the auto-generated id for new notes.
(<https://demo.hedgedoc.org/Q_Iz5T_lQWGYxne0sbMtwg>)
- **shortId**: This refers to the auto-generated short id which is used for "published" notes and slide presentation mode. (https://demo.hedgedoc.org/s/61ZHI6HGE)
- **shortId**: This refers to the auto-generated short id which is used for "published" notes and
slide presentation mode. (<https://demo.hedgedoc.org/s/61ZHI6HGE>)
- **alias**: This refers to user-defined URLs for notes on instances with Free-URL mode enabled. (https://md.kif.rocks/lowercase)
- **alias**: This refers to user-defined URLs for notes on instances with Free-URL mode enabled.
(<https://md.kif.rocks/lowercase>)
The noteId, shortId and alias of each HedgeDoc 1 note are saved as HedgeDoc 2 aliases. Each note gets a newly generated publicId.
The noteId, shortId and alias of each HedgeDoc 1 note are saved as HedgeDoc 2 aliases.
Each note gets a newly generated publicId.
[frontmatter]: https://jekyllrb.com/docs/front-matter/
[base32-encode]: https://www.npmjs.com/package/base32-encode

52
docs/content/dev/design_docs/user_profiles.md
View file

@ -12,7 +12,7 @@ which contains the following information:
- email address, optional (`janedoe@example.com`)
- profile picture, optional
- the date the user was created
- the date the profile was last updated
- the date the profile was last updated
HedgeDoc 2 supports multiple authentication methods per user.
These are called *identities* and each identity is backed by an
@ -23,7 +23,7 @@ This identity is used to automatically update profile attributes like the
display name or profile picture on every login. If a sync source exists, the
user can not manually edit their profile information.
If an external provider was used to create the account,
it is automatically used as sync source.
it is automatically used as sync source.
The administrator may globally set one or more auth providers as sync source,
e.g. to enforce that all profile information comes from the corporate
@ -36,7 +36,7 @@ This effectively pins the account to this provider.
## Example: Corporate LDAP
The administrator wants to allow users to log in via the corporate LDAP
and Google. Login must only be possible for users present in LDAP and
and Google. Login must only be possible for users present in LDAP and
all users must be displayed as they are in the LDAP.
The admin therefore sets up two login providers:
@ -57,16 +57,18 @@ Google account and use it to login afterwards.
HedgeDoc is configured with two auth providers.
- A user logs in using auth provider A.
- The backend receives the profile information from provider A and notices that the username in the profile
already exists in the database, but no identity for this provider-username combination exists.
- The backend receives the profile information from provider A and notices that the username
in the profile already exists in the database, but no identity for this provider-username
combination exists.
- The backend creates a new user with another username to solve the username conflict.
- The frontend warns the user that the username provided by the auth provider is already taken and that another
username has been generated. It also offers to instead link the new auth provider (in this case A) with the
existing auth provider (in this case B).
- If the user chooses the latter option, the frontend sends a request to delete the newly created user to the backend.
- The user can then log in with auth provider B and link provider A using the "link auth provider" feature in
the profile page.
- The frontend warns the user that the username provided by the auth provider is already taken
and that another username has been generated. It also offers to instead link the new auth provider
(in this case A) with the existing auth provider (in this case B).
- If the user chooses the latter option, the frontend sends a request to delete the newly created
user to the backend.
- The user can then log in with auth provider B and link provider A using the "link auth provider"
feature in the profile page.
### Handling of sync sources and username conflicts
#### Global sync sources
@ -77,19 +79,21 @@ the backend cannot automatically create a user with another username.
This is because:
- Creating new accounts is only possible with a sync source auth provider.
- Setting an auth provider as sync-source entails that profile information the auth provider provides must be
saved into the local HedgeDoc database.
- As the username the auth provider provides already exists in the database, a new user cannot be created with
that username.
In this case, the frontend should show the use a notice that they should contact an admin to resolve the issue.
- Setting an auth provider as sync-source entails that profile information the auth provider
provides must be saved into the local HedgeDoc database.
- As the username the auth provider provides already exists in the database, a new user cannot
be created with that username.
In this case, the frontend should show the use a notice that they should contact an admin
to resolve the issue.
!!! warning
Admins must ensure that usernames are unique across all auth providers set as a global sync source.
Otherwise, if e.g. in both LDAPs configured as sync source a user `johndoe` exists,
only the first that logs in can use HedgeDoc.
Admins must ensure that usernames are unique across all auth providers set as a global sync source.
Otherwise, if e.g. in both LDAPs configured as sync source a user `johndoe` exists,
only the first that logs in can use HedgeDoc.
#### Local sync sources
If auth provider A is configured as a sync source by the user, syncing is automatically disabled, and a notice is shown.
Re-enabling the sync source is not possible until the username conflict is resolved, e.g. by changing the username
in the auth provider.
If auth provider A is configured as a sync source by the user, syncing is automatically disabled,
and a notice is shown. Re-enabling the sync source is not possible until the username conflict is
resolved, e.g. by changing the username in the auth provider.

8
docs/content/dev/dev_notes.md
View file

@ -16,17 +16,17 @@ We intend to officially support and test these databases:
The software provides two special groups which have no explicit users:
- `everyone` (Describing that everyone who wants to access a note can do if it is enabled in the config.)
- `everyone` (Describing that everyone who wants to access a note can do if it is
enabled in the config.)
- `loggedIn` (Describing all users which are logged in)
## Entity `create` methods
Because we need to have empty constructors in our entity classes for TypeORM to work, the actual constructor is a separate `create` method. These methods should adhere to these guidelines:
Because we need to have empty constructors in our entity classes for TypeORM to work, the actual
constructor is a separate `create` method. These methods should adhere to these guidelines:
- Only require the non-optional properties of the corresponding entity
- Have no optional parameters
- Have no lists which can be empty (so probably most of them)
- Should either return a complete and fully useable instance or return a Pick/Omit type.
- Exceptions to these rules are allowed, if they are mentioned in the method documentation

9
docs/content/dev/docker.md
View file

@ -1,19 +1,18 @@
# Building Docker images
To build docker images of the backend or frontend use the following commands.
Make sure that you have installed the [Docker BuildKit Plugin](https://docs.docker.com/build/install-buildx/) and
Make sure that you have installed the [Docker BuildKit Plugin][buildkit] and
execute the commands from the root level of the project.
Otherwise, the build process may fail.
```sh
docker buildx build -f backend/docker/Dockerfile -t hedgedoc-backend .
docker buildx build -f backend/docker/Dockerfile -t HedgeDoc-backend .
```
or
```sh
docker buildx build -f frontend/docker/Dockerfile -t hedgedoc-frontend .
docker buildx build -f frontend/docker/Dockerfile -t HedgeDoc-frontend .
```
[buildkit]: https://docs.docker.com/build/install-buildx/

22
docs/content/dev/documentation.md
View file

@ -5,26 +5,30 @@ Our documentation is build with [mkdocs][mkdocs].
## Writing
All documentation files are found in the `docs/content` directory of
the [hedgedoc/hedgedoc repo](https://github.com/hedgedoc/hedgedoc). These files are just normal markdown files with
nothing special about them.
the [HedgeDoc/HedgeDoc repo](https://github.com/hedgedoc/hedgedoc). These files are just normal
markdown files with nothing special about them.
The configuration for mkdocs lies in the `docs` folder in a file called `mkdocs.yml`. With that file the theme and menu - among others - can be configured.
**Please note:** Any new files need to be linked to by other files or put in the navigation, otherwise the files will be very hard to find on the documentation website.
The configuration for mkdocs lies in the `docs` folder in a file called `mkdocs.yml`. With that file
the theme and menu - among others - can be configured.
**Please note:** Any new files need to be linked to by other files or put in the navigation,
otherwise the files will be very hard to find on the documentation website.
## Building
To build the documentation locally you need to perform the following steps:
0. Make sure you have python3 installed.
1. Go into the `docs` folder.
2. Install all the dependencies (E.g. with a [venv](https://docs.python.org/3/library/venv.html))
1. Make sure you have python3 installed.
2. Go into the `docs` folder.
3. Install all the dependencies (E.g. with a [venv](https://docs.python.org/3/library/venv.html))
with `pip install -r requirements.txt`
3. Start the mkdocs dev server (`mkdocs serve`) or build the documentation (`mkdocs build`).
4. Start the mkdocs dev server (`mkdocs serve`) or build the documentation (`mkdocs build`).
## Deployment
The documentation is deployed with [mkdocs][mkdocs].
The repository [docs.hedgedoc.org](https://github.com/hedgedoc/docs.hedgedoc.org) is used to deploy the actual website to github.io. Currently only the `master` branch is deployed as it contains the latest release.
The repository [docs.HedgeDoc.org][docs.HedgeDoc.org] is used to deploy the actual website
to github.io. Currently only the `master` branch is deployed as it contains the latest release.
[mkdocs]: https://www.mkdocs.org
[docs.HedgeDoc.org]: https://github.com/hedgedoc/docs.hedgedoc.org

131
docs/content/dev/getting-started.md
View file

@ -2,35 +2,44 @@
To run HedgeDoc 2.0 you need three components: the backend, the frontend and the reverse proxy.
Backend and Frontend are included in the [HedgeDoc repo](https://github.com/hedgedoc/hedgedoc). The reverse proxy can be chosen by preference. For development, we
recommend caddy and the provided configuration.
Backend and Frontend are included in the [HedgeDoc repo][hedgedoc-repo].
The reverse proxy can be chosen by preference. For development, we recommend caddy
and the provided configuration.
## Quick guide for development setup
This describes the easiest way to start a local development environment. For other deployments follow the description
below.
This describes the easiest way to start a local development environment. For other deployments
follow the description below.
To run HedgeDoc 2.0 you need three components: the backend, the frontend and the reverse proxy.
Backend and Frontend are included in the [HegdeDoc repo](https://github.com/hedgedoc/hedgedoc). The reverse proxy can be chosen by preference. For development, we
recommend caddy and the provided configuration.
Backend and Frontend are included in the [HegdeDoc repo](https://github.com/hedgedoc/hedgedoc).
The reverse proxy can be chosen by preference. For development, we recommend caddy
and the provided configuration.
1. Clone [our repository][hedgedoc-repo] and go into its directory
1. Clone [our repository](https://github.com/hedgedoc/hedgedoc.git) and go into its directory
```shell
git clone https://github.com/hedgedoc/hedgedoc.git
cd hedgedoc
cd HedgeDoc
```
2. Install Node.js. You need at least Node 16, but we recommend Node 20.
3. Install [Yarn](https://yarnpkg.com/getting-started/install)
3. Install [Yarn][yarn]
4. Install Caddy (select one of the two options)
- [Download](https://caddyserver.com/) and place the `caddy` binary in `dev-reverse-proxy`. Ensure it is executable with `chmod +x caddy`. Users of macOS may need to run `xattr -d com.apple.quarantine ./caddy` to lift the quarantine for executables from the internet.
- [Download][caddy] and place the `caddy` binary in `dev-reverse-proxy`.
Ensure it is executable with `chmod +x caddy`. Users of macOS may need to run
`xattr -d com.apple.quarantine ./caddy` to lift the quarantine for executables
from the internet.
- Install Caddy using your package manager
5. Install the dependencies in repo root directory with `yarn install`
6. Create the `.env` config file by copying the example: `cp .env.example .env`
7. Run `yarn start:dev`
> This will execute the backend, frontend and reverse proxy at once
8. Use your browser to go to <http://localhost:8080>. This may take a while because everything is compiled on the fly.
> This will execute the backend, frontend and reverse proxy at once
8. Use your browser to go to <http://localhost:8080>. This may take a while because everything is
compiled on the fly.
## More detailed development setup
The following sections describe a more detailed setup of all components.
## Preconditions
@ -38,35 +47,38 @@ The following sections describe a more detailed setup of all components.
If you want to run HedgeDoc in dev mode some preconditions have to be met.
1. Make sure that Node.js is installed. You need at least Node 16, but we recommend Node 18.
2. Make sure that [Yarn](https://yarnpkg.com/) is installed.
3. Clone this repo (e.g. `git clone https://github.com/hedgedoc/hedgedoc.git hedgedoc`)
2. Make sure that [Yarn][yarn] is installed.
3. Clone this repo (e.g. `git clone https://github.com/hedgedoc/hedgedoc.git HedgeDoc`)
4. Go into the cloned directory
## Installing the dependencies
Because we use Yarn workspaces, Yarn collects the dependencies of all packages automatically in one central top-level
`node_modules` folder.
Because we use Yarn workspaces, Yarn collects the dependencies of all packages automatically in one
central top-level `node_modules` folder.
To install the dependencies execute `yarn install` at the top level of the cloned repository.
Execute this command ONLY there. There is no need to execute the install-command for every package.
It's important to use [Yarn](https://yarnpkg.com/). We don't support `npm` or any other package manager and using anything
else than Yarn won't work.
It's important to use [Yarn][yarn]. We don't support `npm` or any other package
manager and using anything else than Yarn won't work.
## Create the configuration
HedgeDoc 2 is configured using environment variables.
For development, we recommend creating an `.env` file.
1. Create an `.env` file. We recommend to use the example file by running `cp .env.example .env`
You can modify this file according to the [configuration documentation](../config/index.md).
2. Make sure that you've set `HD_SESSION_SECRET` in your `.env` file. Otherwise, the backend won't start.
> In dev mode you don't need a secure secret. So use any value. If you want to generate a secure session secret you
can use e.g. `openssl rand -hex 16 | sed -E 's/(.*)/HD_SESSION_SECRET=\1/' >> .env`.
3. Make sure that `HD_BASE_URL` in `.env` is set to the base url where HedgeDoc should be available. In local dev
environment this is most likely `http://localhost:8080`.
You can modify this file according to the [configuration documentation][config-docs].
2. Make sure that you've set `HD_SESSION_SECRET` in your `.env` file. Otherwise, the backend
won't start.
> In dev mode you don't need a secure secret. So use any value. If you want to generate a secure
> session secret you can use
> e.g. `openssl rand -hex 16 | sed -E 's/(.*)/HD_SESSION_SECRET=\1/' >> .env`.
3. Make sure that `HD_BASE_URL` in `.env` is set to the base url where HedgeDoc should be available.
In local dev environment this is most likely `http://localhost:8080`.
## Build the `commons` package
Some code is shared by backend and frontend. This code lives in the `commons package and needs to be built so
frontend and backend can import it.
Some code is shared by backend and frontend. This code lives in the `commons package and needs
to be built so frontend and backend can import it.
This only needs to be done once, except if you've changed code in the commons package.
1. Go into the `commons` directory.
@ -74,25 +86,28 @@ This only needs to be done once, except if you've changed code in the commons pa
## Setting up the Backend
**Note:** The backend can be mocked instead of starting it for real. This is useful, if you just want to work on the frontend. See the "Mocked backend" section below.
**Note:** The backend can be mocked instead of starting it for real. This is useful,
if you just want to work on the frontend. See the "Mocked backend" section below.
1. Go into the `backend` directory.
2. Start the backend by running `yarn start:dev` for dev mode or `yarn start` for production.
## Setting up the frontend
The frontend can be run in four different ways. The development mode compiles everything on demand. So the first time
you open a page in the browser it may take some time.
See [here](setup/frontend.md) for a more detailed description of the environment variables for the frontend.
A special configuration isn't necessary but keep in mind that you execute all commands from within the `frontend` directory.
The frontend can be run in four different ways. The development mode compiles everything on demand.
So the first time you open a page in the browser it may take some time.
[See here][frontend-setup] for a more detailed description of the environment variables
for the frontend. A special configuration isn't necessary but keep in mind that you execute
all commands from within the `frontend` directory.
### Mocked backend
This task will run the frontend in mock-mode, meaning instead of running a real backend, the frontend mocks the backend.
This way you can work on frontend functionality without starting up the full development environment.
The downside of this method is that you can't save notes and that realtime collaboration features are not available.
To start the development mode, run `yarn start:dev:mock`.
The app should run now and be available under [http://localhost:3001](http://localhost:3001) in your browser.
This task will run the frontend in mock-mode, meaning instead of running a real backend, the
frontend mocks the backend. This way you can work on frontend functionality without starting up the
full development environment. The downside of this method is that you can't save notes and that
realtime collaboration features are not available. To start the development mode,
run `yarn start:dev:mock`. The app should run now and be available under
<http://localhost:3001> in your browser.
### With local backend
@ -101,31 +116,43 @@ This task will automatically set `HD_BASE_URL` to `http://localhost:8080`.
### Production mode
Use `yarn build` to build the app in production mode and save it into the `.next` folder. The production build is
minimized and optimized for best performance. Don't edit the generated files in the `.next` folder in any way!
Use `yarn build` to build the app in production mode and save it into the `.next` folder.
The production build is minimized and optimized for best performance. Don't edit the generated
files in the `.next` folder in any way!
You can run the production build using the built-in server with `yarn start`.
You MUST provide the environment variable `HD_BASE_URL` with protocol, domain and (if needed) subdirectory path (
e.g. `http://localhost:3001/`) so the app knows under which URL the frontend is available in the browser.
You MUST provide the environment variable `HD_BASE_URL` with protocol, domain and (if needed)
subdirectory path (e.g. `http://localhost:3001/`) so the app knows under which URL the frontend
is available in the browser.
If you use the production build then make sure that you set the environment variable `HD_BASE_URL` to the same
value as `HD_BASE_URL` in the backend.
If you use the production build then make sure that you set the environment variable `HD_BASE_URL`
to the same value as `HD_BASE_URL` in the backend.
### Production mock build
It is also possible to create a production build that uses the emulated backend by using `yarn build:mock`. This is
usually not needed except for demonstration purposes like `https://hedgedoc.dev`.
It is also possible to create a production build that uses the emulated backend by using
`yarn build:mock`. This is usually not needed except for demonstration purposes like
`https://hedgedoc.dev`.
## Running backend and frontend together
To use backend and frontend together in development mode you'll need a local reverse proxy that combines both services
under one URL origin.
We recommend to use our pre-configured [Caddy](https://caddyserver.com/) configuration.
To use backend and frontend together in development mode you'll need a local reverse proxy that
combines both services under one URL origin.
We recommend to use our pre-configured [Caddy][caddy] configuration.
### Running the reverse proxy
1. Download the latest version of Caddy from [the Caddy website](https://caddyserver.com/) or alternatively install it
using your package manager. You don't need any plugin. Place the downloaded binary in the
directory `dev-reverse-proxy`. Don't forget to mark the file as executable using `chmod +x caddy`. Users of macOS may need to run `xattr -d com.apple.quarantine ./caddy` to lift the quarantine for executables from the internet.
2. Start Caddy using `./caddy run` (if you downloaded the binary manually) or `caddy run` (if you installed Caddy via a package manager).
3. Open your browser on http://localhost:8080
1. Download the latest version of Caddy from [the Caddy website][caddy] or alternatively install
it using your package manager. You don't need any plugin. Place the downloaded binary in
the directory `dev-reverse-proxy`. Don't forget to mark the file as executable using
`chmod +x caddy`. Users of macOS may need to run `xattr -d com.apple.quarantine ./caddy`
to lift the quarantine for executables from the internet.
2. Start Caddy using `./caddy run` (if you downloaded the binary manually) or `caddy run`
(if you installed Caddy via a package manager).
3. Open your browser on <http://localhost:8080>
[hedgedoc-repo]: https://github.com/hedgedoc/hedgedoc
[yarn]: https://yarnpkg.com/getting-started/install
[caddy]: https://caddyserver.com/
[config-docs]: ../config/index.md
[frontend-setup]: ./setup/frontend.md

42
docs/content/dev/setup/frontend.md
View file

@ -1,31 +1,26 @@
<!--
SPDX-FileCopyrightText: 2021 The HedgeDoc developers (see AUTHORS file)
SPDX-License-Identifier: CC-BY-SA-4.0
-->
# Frontend
## Environment Variables
The following environment variables are recognized by the frontend process.
| Name | Possible Values | Description |
|--------------------------|----------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| HD_BASE_URL | Any URL with protocol, domain and optionally directory and port. Must end with a trailing slash. (e.g. `http://localhost:3001/`) | The URL under which the frontend is expected. Setting this is mandatory so the server side rendering can generate assets URLs. You only need to set this yourself if you use the production mode. |
| HD_RENDERER_BASE_URL | Same as `HD_BASE_URL` | You can provide this variable if the renderer should use another domain than the editor. This is recommended for security reasons but not mandatory. This variable is optional and will fallback to `HD_BASE_URL` |
| HD_RENDERER_BASE_URL | Same as `HD_BASE_URL` | You can provide this variable if the renderer should use another domain than the editor. This is recommended for security reasons but not mandatory. This variable is optional and will fallback to `HD_BASE_URL` |
| NEXT_PUBLIC_USE_MOCK_API | `true`, `false` | Will activate the mocked backend |
| NEXT_PUBLIC_TEST_MODE | `true`, `false` | Will activate additional HTML attributes that are used to identify elements for test suits. |
Variables that start with `NEXT_PUBLIC_` will be compiled into the build. You can't change them at after compilation.
You shouldn't need to set them yourself. Use the designated npm tasks instead.
Variables that start with `NEXT_PUBLIC_` will be compiled into the build. You can't change them at
after compilation. You shouldn't need to set them yourself. Use the designated npm tasks instead.
## UI Test
Curious about the new look and feel? We provide a demo of the new UI on [hedgedoc.dev](https://hedgedoc.dev). This
version uses mocked data and has no data persistence.
Curious about the new look and feel? We provide a demo of the new UI on
[HedgeDoc.dev][hedgedoc-dev]. This version uses mocked data and has no data persistence.
The UI test is hosted by [netlify](https://netlify.com). Please check
their [privacy policy](https://netlify.com/privacy) as well as [ours](https://hedgedoc.org/privacy-policy).
The UI test is hosted by [netlify][netlify]. Please check their [privacy policy][netlify-privacy]
as well as [ours][privacy].
## Running Tests
@ -37,10 +32,10 @@ Unit testing is done via jest.
### End2End
We use [cypress](https://cypress.io) for e2e tests.
We use [cypress][cypress] for e2e tests.
1. Start the frontend with `yarn start:dev:test` (or use a test build using `yarn build:test` which you can start
using `yarn start`). The usage of `:test` is mandatory!
1. Start the frontend with `yarn start:dev:test` (or use a test build using `yarn build:test`
which you can start using `yarn start`). The usage of `:test` is mandatory!
2. Run `yarn cy:open` to open the cypress test loader
3. Choose your browser and start a test suite
@ -55,9 +50,16 @@ You can inspect the generated production-bundle files to look for optimization i
## Enable Debug Logging in Production
The debug logger can be enabled in production by setting `debugLogging` in the browser's local storage to `true`.
This can be done e.g. by executing this JavaScript command in the browser's console.
The debug logger can be enabled in production by setting `debugLogging` in the browser's
local storage to `true`. This can be done e.g. by executing this JavaScript command
in the browser's console.
```javascript
window.localStorage.setItem("debugLogging", 'true');
window.localStorage.setItem("debugLogging", "true");
```
[hedgedoc-dev]: https://hedgedoc.dev
[netlify]: https://netlify.com
[netlify-privacy]: https://netlify.com/privacy
[privacy]: https://hedgedoc.org/privacy-policy
[cypress]: https://cypress.io