From 91a21c272960889afd4eaa431a3d29b7785b6efc Mon Sep 17 00:00:00 2001 From: nodiscc Date: Sat, 16 May 2020 12:54:51 +0200 Subject: **General rewording, proof-reading, deduplication, shortening, reordering, simplification, cleanup/formatting/standardization** - standardize page names, rework documentation structure, update TOC - use same example paths everywhere - level 1 titles on all pages - fix broken links - .md suffix on all page links (works both from readthedocs and github repository views) **Server:** A full and concise installation guide with examples is a frequent request. The documentation should provide such a guide for basic installation needs, while explaining alternative/advanced configuration at the end. Links to reference guides and documentation should be used more frequently to avoid recommending an outdated or excessively complex configuration. - server: move most server-related info to server-configuration.md, cleanup/shorten - server: update list of php dependencies/libraries, link to composer.json - server: installation: support 3 install methods (from release zip, from sources, using docker) - server: installation: use rsync instead of mv as mv results will change depending of taget directory already existing or not - server: add example/basic usage of certbot - server, upgrade, installation: update file permissions setup, use sudo for upgrade operations in webserver document root - server: apache: add comments to configuration, fix and factorize file permissions setup, set cache-control header, deny access to dotfiles, add missing apache config steps, add http->https redirect example - server: nginx: refactor nginx configuration, add comments, DO log access to denied/protected files - server: add links to MDN for x-forwarded-* http headers explanation, cleanup/clarify robots.txt and crawlers section - server: bump file upload size limit to 100MB we have reports of bookmark exports weighing +40MB - i have a 13MB one here - server: simplify phpinfo documentation - server: move backup and restore information to dedicated page - docker: move all docker docs to Docker.md, simplify/ docker setup, add docker-compose.yml example, replace docker-101 with docker cheatsheet - troubleshooting: move all troubleshooting documentation to troubleshooting.md **Usage:** - index: add getting started section on index page - features/usage: move all usage-related documentation to usage.md, add links from the main feature list to corresponding usage docs, clarify/reword features list - shaarli configuration: add note about configuring from web interface **Removed:** - remove obsolete/orphan images - remove obsolete shaarchiver example - remove outdated "decode datastore content" snippet **Development:** - development: move development-related docs (static analysis, CI, unit tests, 3rd party libs, link structure/directory, guidelines, security....) to dev/ directory - development: Merge several pages to development.md - **Breaking change?:** remove mentions of 'stable' branch, switch to new branch/release model (master=latest commit, release=latest tag) - **Breaking change?:** refer to base sharing unit as "Shaare" everywhere (TODO: reflect changes in the code?) doc: update featues list/link to usage.md for details - development: directory structure: add note about required file permissions - .travis-ci.yml: add comments - .htaccess: add comment --- doc/md/REST-API.md | 159 +++++++++++++++++++++++------------------------------ 1 file changed, 68 insertions(+), 91 deletions(-) (limited to 'doc/md/REST-API.md') diff --git a/doc/md/REST-API.md b/doc/md/REST-API.md index 11bd1cd2..01071d8e 100644 --- a/doc/md/REST-API.md +++ b/doc/md/REST-API.md @@ -1,101 +1,24 @@ -## Usage and Prerequisites +# REST API -See the [REST API documentation](http://shaarli.github.io/api-documentation/) -for a list of available endpoints and parameters. +## Server requirements -Please ensure that your server meets the -[requirements](Server-configuration#prerequisites) and is properly -[configured](Server-configuration): +See the **[REST API documentation](http://shaarli.github.io/api-documentation/)** for a list of available endpoints and parameters. + +Please ensure that your server meets the requirements and is properly [configured](Server-configuration): - URL rewriting is enabled (see specific Apache and Nginx sections) - the server's timezone is properly defined -- the server's clock is synchronized with - [NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) - -The host where the API client is invoked should also be synchronized with NTP, -see [token expiration](#payload). - -## Authentication - -All requests to Shaarli's API must include a JWT token to verify their authenticity. - -This token has to be included as an HTTP header called `Authentication: Bearer `. - -JWT resources : - -- [jwt.io](https://jwt.io) (including a list of client per language). -- RFC : https://tools.ietf.org/html/rfc7519 -- https://float-middle.com/json-web-tokens-jwt-vs-sessions/ -- HackerNews thread: https://news.ycombinator.com/item?id=11929267 - - -### Shaarli JWT Token - -JWT tokens are composed by three parts, separated by a dot `.` and encoded in base64: - -``` -[header].[payload].[signature] -``` - -#### Header - -Shaarli only allow one hash algorithm, so the header will always be the same: - -```json -{ - "typ": "JWT", - "alg": "HS512" -} -``` - -Encoded in base64, it gives: - -``` -ewogICAgICAgICJ0eXAiOiAiSldUIiwKICAgICAgICAiYWxnIjogIkhTNTEyIgogICAgfQ== -``` - -#### Payload - -**Token expiration** - -To avoid infinite token validity, JWT tokens must include their creation date -in UNIX timestamp format (timezone independent - UTC) under the key `iat` (issued at). -This token will be valid during **9 minutes**. - -```json -{ - "iat": 1468663519 -} -``` - -See [RFC reference](https://tools.ietf.org/html/rfc7519#section-4.1.6). - +- the server's clock is synchronized with [NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) -#### Signature - -The signature authenticate the token validity. It contains the base64 of the header and the body, separated by a dot `.`, hashed in SHA512 with the API secret available in Shaarli administration page. - -Signature example with PHP: - -```php -$content = base64_encode($header) . '.' . base64_encode($payload); -$signature = hash_hmac('sha512', $content, $secret); -``` +The host where the API client is invoked should also be synchronized with NTP, see _payload/token expiration_ ## Clients and examples -### Android, Java, Kotlin - -- [Android client example with Kotlin](https://gitlab.com/snippets/1665808) - by [Braincoke](https://github.com/Braincoke) - -### Javascript, NodeJS -- [shaarli-client](https://www.npmjs.com/package/shaarli-client) - ([source code](https://github.com/laBecasse/shaarli-client)) - by [laBecasse](https://github.com/laBecasse) +- **[python-shaarli-client](https://github.com/shaarli/python-shaarli-client)** - the reference API client ([Documentation](http://python-shaarli-client.readthedocs.io/en/latest/)) +- [shaarli-client](https://www.npmjs.com/package/shaarli-client) - NodeJs client ([source code](https://github.com/laBecasse/shaarli-client)) by [laBecasse](https://github.com/laBecasse) +- [Android client example with Kotlin](https://gitlab.com/snippets/1665808) by [Braincoke](https://github.com/Braincoke) -### PHP This example uses the [PHP cURL](http://php.net/manual/en/book.curl.php) library. @@ -145,13 +68,57 @@ function getInfo($baseUrl, $secret) { var_dump(getInfo($baseUrl, $secret)); ``` +## Implementation + +### Authentication + +- All requests to Shaarli's API must include a **JWT token** to verify their authenticity. +- This token must be included as an HTTP header called `Authentication: Bearer `. +- JWT tokens are composed by three parts, separated by a dot `.` and encoded in base64: + +``` +[header].[payload].[signature] +``` + +##### Header + +Shaarli only allow one hash algorithm, so the header will always be the same: + +```json +{ + "typ": "JWT", + "alg": "HS512" +} +``` + +Encoded in base64, it gives: -### Python +``` +ewogICAgICAgICJ0eXAiOiAiSldUIiwKICAgICAgICAiYWxnIjogIkhTNTEyIgogICAgfQ== +``` + +##### Payload + +Token expiration: To avoid infinite token validity, JWT tokens must include their creation date in UNIX timestamp format (timezone independent - UTC) under the key `iat` (issued at) field ([1](https://tools.ietf.org/html/rfc7519#section-4.1.6)). This token will be valid during **9 minutes**. + +```json +{ + "iat": 1468663519 +} +``` + +##### Signature + +The signature authenticates the token validity. It contains the base64 of the header and the body, separated by a dot `.`, hashed in SHA512 with the API secret available in Shaarli administration page. + +Example signature with PHP: + +```php +$content = base64_encode($header) . '.' . base64_encode($payload); +$signature = hash_hmac('sha512', $content, $secret); +``` -See the reference API client: -- [Documentation](http://python-shaarli-client.readthedocs.io/en/latest/) on ReadTheDocs -- [python-shaarli-client](https://github.com/shaarli/python-shaarli-client) on Github ## Troubleshooting @@ -171,3 +138,13 @@ to get the actual error message in the HTTP response body with: } } ``` + +## References + +- [jwt.io](https://jwt.io) (including a list of client per language). +- [RFC - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519) +- [JSON Web Tokens (JWT) vs Sessions](https://float-middle.com/json-web-tokens-jwt-vs-sessions/), [HackerNews thread](https://news.ycombinator.com/item?id=11929267) + + + + -- cgit v1.2.3