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

docs: consistent Markdown formatting

Browse source 
Signed-off-by: David Mehren <git@herrmehren.de>
This commit is contained in:
David Mehren 2023-03-19 17:01:11 +01:00
parent 31969c56eb
commit 26da4c6327
3 changed files with 9 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -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.
## Public API
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
@ -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.
#### 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,
@ -38,7 +40,7 @@ SHA-512 (or alternatively SHA3) fits this use-case.
## Private API
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
using one of the supported authentication methods:

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

@ -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.
## 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
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.
## Example: Username Conflict
HedgeDoc is configured with two auth providers.
- 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
#### Global sync sources
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.