mirror of
https://github.com/hedgedoc/hedgedoc.git
synced 2024-11-22 01:36:29 -05:00
docs: consistent Markdown formatting
Signed-off-by: David Mehren <git@herrmehren.de>
This commit is contained in:
parent
31969c56eb
commit
26da4c6327
3 changed files with 9 additions and 1 deletions
|
@ -5,6 +5,7 @@ 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.
|
feature. It is not a user guide and may or may not be fully implemented.
|
||||||
|
|
||||||
## Public API
|
## 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](https://datatracker.ietf.org/doc/html/rfc6750).
|
||||||
|
|
||||||
This token can be generated using the profile page in the frontend
|
This token can be generated using the profile page in the frontend
|
||||||
|
@ -20,6 +21,7 @@ A SHA-512 hash of the secret is stored in the database. To validate tokens, the
|
||||||
secret and checks it against the stored hash for the provided identifier.
|
secret and checks it against the stored hash for the provided identifier.
|
||||||
|
|
||||||
#### Choosing a hash function
|
#### Choosing a hash function
|
||||||
|
|
||||||
Unfortunately, there does not seem to be any explicit documentation about our exact use-case.
|
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.
|
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,
|
These hashing functions are slow to stop brute-force or dictionary attacks, which would expose the original,
|
||||||
|
@ -38,7 +40,7 @@ SHA-512 (or alternatively SHA3) fits this use-case.
|
||||||
## Private API
|
## Private API
|
||||||
|
|
||||||
The private API uses a session cookie to authenticate the user.
|
The private API uses a session cookie to authenticate the user.
|
||||||
Sessions are handled using passport.js.
|
Sessions are handled using [passport.js](https://www.passportjs.org/).
|
||||||
|
|
||||||
The backend hands out a new session token after the user has successfully authenticated
|
The backend hands out a new session token after the user has successfully authenticated
|
||||||
using one of the supported authentication methods:
|
using one of the supported authentication methods:
|
||||||
|
|
|
@ -34,6 +34,7 @@ is automatically set as sync source and cannot be changed by the user.
|
||||||
This effectively pins the account to this provider.
|
This effectively pins the account to this provider.
|
||||||
|
|
||||||
## Example: Corporate LDAP
|
## Example: Corporate LDAP
|
||||||
|
|
||||||
The administrator wants to allow users to log in via the 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.
|
all users must be displayed as they are in the LDAP.
|
||||||
|
@ -52,6 +53,7 @@ the 'add a new login method' feature in their profile page to link their
|
||||||
Google account and use it to login afterwards.
|
Google account and use it to login afterwards.
|
||||||
|
|
||||||
## Example: Username Conflict
|
## Example: Username Conflict
|
||||||
|
|
||||||
HedgeDoc is configured with two auth providers.
|
HedgeDoc is configured with two auth providers.
|
||||||
|
|
||||||
- A user logs in using auth provider A.
|
- A user logs in using auth provider A.
|
||||||
|
@ -68,6 +70,7 @@ HedgeDoc is configured with two auth providers.
|
||||||
### Handling of sync sources and username conflicts
|
### Handling of sync sources and username conflicts
|
||||||
|
|
||||||
#### Global sync sources
|
#### Global sync sources
|
||||||
|
|
||||||
If at the time of logging in with auth provider A, *only* A is configured as a *global* sync source,
|
If at the time of logging in with auth provider A, *only* A is configured as a *global* sync source,
|
||||||
the backend cannot automatically create a user with another username.
|
the backend cannot automatically create a user with another username.
|
||||||
|
|
||||||
|
|
|
@ -1,9 +1,11 @@
|
||||||
# Development Notes
|
# Development Notes
|
||||||
|
|
||||||
This document collects notes and decisions taken during the development of HedgeDoc 2.0.
|
This document collects notes and decisions taken during the development of HedgeDoc 2.0.
|
||||||
It should be converted to a properly structured documentation, but having unstructured docs
|
It should be converted to a properly structured documentation, but having unstructured docs
|
||||||
is better than having no docs.
|
is better than having no docs.
|
||||||
|
|
||||||
## Supported databases
|
## Supported databases
|
||||||
|
|
||||||
We intend to officially support and test these databases:
|
We intend to officially support and test these databases:
|
||||||
|
|
||||||
- SQLite (for development and smaller instances)
|
- SQLite (for development and smaller instances)
|
||||||
|
@ -11,6 +13,7 @@ We intend to officially support and test these databases:
|
||||||
- MariaDB
|
- MariaDB
|
||||||
|
|
||||||
## Special Groups
|
## Special Groups
|
||||||
|
|
||||||
The software provides two special groups which have no explicit users:
|
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.)
|
||||||
|
|
Loading…
Reference in a new issue