diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/API/differences_in_mastoapi_responses.md | 15 | ||||
-rw-r--r-- | docs/configuration/hardening.md | 2 | ||||
-rw-r--r-- | docs/dev.md | 23 |
3 files changed, 38 insertions, 2 deletions
diff --git a/docs/API/differences_in_mastoapi_responses.md b/docs/API/differences_in_mastoapi_responses.md index 1059155cf..289f85930 100644 --- a/docs/API/differences_in_mastoapi_responses.md +++ b/docs/API/differences_in_mastoapi_responses.md @@ -4,7 +4,7 @@ A Pleroma instance can be identified by "<Mastodon version> (compatible; Pleroma ## Flake IDs -Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However just like Mastodon's ids they are sortable strings +Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However just like Mastodon's ids they are lexically sortable strings ## Attachment cap @@ -14,6 +14,7 @@ Some apps operate under the assumption that no more than 4 attachments can be re Adding the parameter `with_muted=true` to the timeline queries will also return activities by muted (not by blocked!) users. Adding the parameter `exclude_visibilities` to the timeline queries will exclude the statuses with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`), e.g., `exclude_visibilities[]=direct&exclude_visibilities[]=private`. +Adding the parameter `reply_visibility` to the public and home timelines queries will filter replies. Possible values: without parameter (default) shows all replies, `following` - replies directed to you or users you follow, `self` - replies directed to you. ## Statuses @@ -119,6 +120,18 @@ Accepts additional parameters: - `exclude_visibilities`: will exclude the notifications for activities with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`). Usage example: `GET /api/v1/notifications?exclude_visibilities[]=direct&exclude_visibilities[]=private`. - `include_types`: will include the notifications for activities with the given types. The parameter accepts an array of types (`mention`, `follow`, `reblog`, `favourite`, `move`, `pleroma:emoji_reaction`). Usage example: `GET /api/v1/notifications?include_types[]=mention&include_types[]=reblog`. +## DELETE `/api/v1/notifications/destroy_multiple` + +An endpoint to delete multiple statuses by IDs. + +Required parameters: + +- `ids`: array of activity ids + +Usage example: `DELETE /api/v1/notifications/destroy_multiple/?ids[]=1&ids[]=2`. + +Returns on success: 200 OK `{}` + ## POST `/api/v1/statuses` Additional parameters can be added to the JSON body/Form data: diff --git a/docs/configuration/hardening.md b/docs/configuration/hardening.md index b54c28850..d3bfc4e4a 100644 --- a/docs/configuration/hardening.md +++ b/docs/configuration/hardening.md @@ -36,7 +36,7 @@ content-security-policy: default-src 'none'; base-uri 'self'; frame-ancestors 'none'; - img-src 'self' data: https:; + img-src 'self' data: blob: https:; media-src 'self' https:; style-src 'self' 'unsafe-inline'; font-src 'self'; diff --git a/docs/dev.md b/docs/dev.md new file mode 100644 index 000000000..f1b4cbf8b --- /dev/null +++ b/docs/dev.md @@ -0,0 +1,23 @@ +This document contains notes and guidelines for Pleroma developers. + +# Authentication & Authorization + +## OAuth token-based authentication & authorization + +* Pleroma supports hierarchical OAuth scopes, just like Mastodon but with added granularity of admin scopes. For a reference, see [Mastodon OAuth scopes](https://docs.joinmastodon.org/api/oauth-scopes/). + +* It is important to either define OAuth scope restrictions or explicitly mark OAuth scope check as skipped, for every controller action. To define scopes, call `plug(Pleroma.Plugs.OAuthScopesPlug, %{scopes: [...]})`. To explicitly set OAuth scopes check skipped, call `plug(:skip_plug, Pleroma.Plugs.OAuthScopesPlug <when ...>)`. + +* In controllers, `use Pleroma.Web, :controller` will result in `action/2` (see `Pleroma.Web.controller/0` for definition) be called prior to actual controller action, and it'll perform security / privacy checks before passing control to actual controller action. + + For routes with `:authenticated_api` pipeline, authentication & authorization are expected, thus `OAuthScopesPlug` will be run unless explicitly skipped (also `EnsureAuthenticatedPlug` will be executed immediately before action even if there was an early run to give an early error, since `OAuthScopesPlug` supports `:proceed_unauthenticated` option, and other plugs may support similar options as well). + + For `:api` pipeline routes, it'll be verified whether `OAuthScopesPlug` was called or explicitly skipped, and if it was not then auth information will be dropped for request. Then `EnsurePublicOrAuthenticatedPlug` will be called to ensure that either the instance is not private or user is authenticated (unless explicitly skipped). Such automated checks help to prevent human errors and result in higher security / privacy for users. + +## [HTTP Basic Authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) + +* With HTTP Basic Auth, OAuth scopes check is _not_ performed for any action (since password is provided during the auth, requester is able to obtain a token with full permissions anyways). `Pleroma.Plugs.AuthenticationPlug` and `Pleroma.Plugs.LegacyAuthenticationPlug` both call `Pleroma.Plugs.OAuthScopesPlug.skip_plug(conn)` when password is provided. + +## Auth-related configuration, OAuth consumer mode etc. + +See `Authentication` section of [`docs/configuration/cheatsheet.md`](docs/configuration/cheatsheet.md#authentication). |