mirror of
https://github.com/CommunitySolidServer/CommunitySolidServer.git
synced 2024-10-03 14:55:10 +00:00
style: Enforce linting rules on markdown files
* chore: add markdownlint-cli2 and config for mkdocs * style: enforce linting rules on mkdocs md files * chore: tweaks to markdownlint rules * style: linting changelog * style: linting release notes * style: linting .github md files * style: further linting of docs * style: linting readmes * chore: update linting script entries * docs: tweak release after rebase * chore: simplify root md linting config * chore: extend base config * chore: implement requested changes * chore: remove unnecessary exception * chore: fix comment type * styling: single config + list spacing * chore: implement requested changes * chore: use .cjs files for markdownlint config * chore: implement requested changes
This commit is contained in:
Jasper Vaneessen
GitHub
parent
04695e7651
commit
9a5fc674f3
14
.github/.markdownlint-cli2.cjs
vendored
Normal file
14
.github/.markdownlint-cli2.cjs
vendored
Normal file
@ -0,0 +1,14 @@
|
||||
|
||||
const options = require('../.markdownlint-cli2.cjs');
|
||||
"use strict";
|
||||
|
||||
module.exports = {
|
||||
globs: [ "**/*.md" ],
|
||||
config: {
|
||||
// Re-use the base config
|
||||
...options.config,
|
||||
|
||||
// Allow first line to not be top level heading
|
||||
MD041: false
|
||||
}
|
||||
};
|
||||
4
.github/ISSUE_TEMPLATE/bug-report.md
vendored
4
.github/ISSUE_TEMPLATE/bug-report.md
vendored
@ -8,7 +8,9 @@ assignees: ''
|
||||
---
|
||||
|
||||
#### Environment
|
||||
- Server version: *Output of `community-solid-server --version` for a global or `npx community-solid-server --version` for a local installation*
|
||||
|
||||
- Server version: *Output of `community-solid-server --version` for a
|
||||
global or `npx community-solid-server --version` for a local installation*
|
||||
- Node.js version: *Output of `node -v`*
|
||||
- npm version: *Output of `npm -v`*
|
||||
|
||||
|
||||
2
.github/ISSUE_TEMPLATE/feature-request.md
vendored
2
.github/ISSUE_TEMPLATE/feature-request.md
vendored
@ -7,7 +7,7 @@ assignees: ''
|
||||
|
||||
---
|
||||
|
||||
#### Feature description:
|
||||
#### Feature description
|
||||
|
||||
<!--In case you want to start a discussion about an idea, discussions are better suited for this https://github.com/CommunitySolidServer/CommunitySolidServer/discussions -->
|
||||
<!--A clear and concise description of what you want to happen.-->
|
||||
|
||||
18
.github/PULL_REQUEST_TEMPLATE.md
vendored
18
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -1,6 +1,6 @@
|
||||
#### 📁 Related issues
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Reference any relevant issues here. Closing keywords only have an effect when targeting the main branch. If there are no related issues, you must first create an issue through https://github.com/CommunitySolidServer/CommunitySolidServer/issues/new/choose
|
||||
-->
|
||||
|
||||
@ -8,16 +8,16 @@ Reference any relevant issues here. Closing keywords only have an effect when ta
|
||||
|
||||
<!-- Describe the relevant changes in this PR. Also add notes that might be relevant for code reviewers. -->
|
||||
|
||||
|
||||
### ✅ PR check list
|
||||
|
||||
Before this pull request can be merged, a core maintainer will check whether
|
||||
* [ ] this PR is labeled with the correct semver label
|
||||
- semver.patch: Backwards compatible bug fixes.
|
||||
- semver.minor: Backwards compatible feature additions.
|
||||
- semver.major: Breaking changes. This includes changing interfaces or configuration behaviour.
|
||||
* [ ] the correct branch is targeted. Patch updates can target main, other changes should target the latest versions/* branch.
|
||||
* [ ] the RELEASE_NOTES.md document in case of relevant feature or config changes.
|
||||
* [ ] any relevant documentation was updated to reflect the changes in this PR.
|
||||
|
||||
* [ ] this PR is labeled with the correct semver label
|
||||
* semver.patch: Backwards compatible bug fixes.
|
||||
* semver.minor: Backwards compatible feature additions.
|
||||
* semver.major: Breaking changes. This includes changing interfaces or configuration behaviour.
|
||||
* [ ] the correct branch is targeted. Patch updates can target main, other changes should target the latest versions/* branch.
|
||||
* [ ] the RELEASE_NOTES.md document in case of relevant feature or config changes.
|
||||
* [ ] any relevant documentation was updated to reflect the changes in this PR.
|
||||
|
||||
<!-- Try to check these to the best of your abilities before opening the PR -->
|
||||
|
||||
31
.markdownlint-cli2.cjs
Normal file
31
.markdownlint-cli2.cjs
Normal file
@ -0,0 +1,31 @@
|
||||
"use strict";
|
||||
|
||||
module.exports = {
|
||||
ignores: [ "node_modules/", "LICENSE.md" ],
|
||||
|
||||
globs: [ "**/*.md" ],
|
||||
|
||||
config: {
|
||||
// Enable all markdownlint rules
|
||||
default: true,
|
||||
|
||||
// Set list indent level to 4 which mkdocs / Python-Markdown requires
|
||||
MD007: { "indent": 4 },
|
||||
|
||||
// Enable line length check but exclude tables and code blocks
|
||||
MD013: {
|
||||
line_length: 120,
|
||||
tables: false,
|
||||
code_blocks: false
|
||||
},
|
||||
|
||||
// Allow multiple subheadings with the same content
|
||||
// across different section (#1 ##A ##B #2 ##A ##B)
|
||||
MD024: {
|
||||
allow_different_nesting: true
|
||||
},
|
||||
|
||||
// Set Ordered list item prefix to "ordered" (use 1. 2. 3. not 1. 1. 1.)
|
||||
MD029: { "style": "ordered" }
|
||||
}
|
||||
};
|
||||
@ -10,6 +10,6 @@
|
||||
{"type": "perf", "section": "Performance"},
|
||||
{"type": "test", "section": "Testing"}
|
||||
],
|
||||
"header": "# Changelog\n\nAll notable changes to this project will be documented in this file.",
|
||||
"header": "<!-- markdownlint-disable MD013 -->\n# Changelog\n\nAll notable changes to this project will be documented in this file.",
|
||||
"releaseCommitMessageFormat": "chore(release): Release version {{currentTag}} of the npm package"
|
||||
}
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
<!-- markdownlint-disable MD013 -->
|
||||
# Changelog
|
||||
|
||||
All notable changes to this project will be documented in this file.
|
||||
|
||||
## [5.0.0](https://github.com/CommunitySolidServer/CommunitySolidServer/compare/v4.0.1...v5.0.0) (2022-08-08)
|
||||
|
||||
### Features
|
||||
@ -277,16 +279,16 @@ All notable changes to this project will be documented in this file.
|
||||
|
||||
## [1.0.0](https://github.com/solid/community-server/compare/v1.0.0-beta.2...v1.0.0) (2021-08-04)
|
||||
|
||||
## Added
|
||||
### Added
|
||||
|
||||
* feat: Create ChainedTemplateEngine for combining engines ([18a7103](https://github.com/solid/community-server/commit/18a71032c0ba872a3acd08fa1c63136fdf6489de))
|
||||
* feat: Accept asset paths as config. ([f28279e](https://github.com/solid/community-server/commit/f28279e3a577072adb9ff27b2a54a1624076a448))
|
||||
|
||||
## Changed
|
||||
### Changed
|
||||
|
||||
* change: Use @css: instead of $PACKAGE_ROOT/ ([1719857](https://github.com/solid/community-server/commit/1719857e4b340fd16cdde9d9a45097072cc68fe2))
|
||||
|
||||
## Fixed
|
||||
### Fixed
|
||||
|
||||
* fix: Replace rimraf with fs-extra.remove ([2a82c4f](https://github.com/solid/community-server/commit/2a82c4f06e25981205d0841fe473d038888bc3ef))
|
||||
|
||||
|
||||
@ -1 +1,3 @@
|
||||
# Code of conduct
|
||||
|
||||
We follow and adhere to the Solid [Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md).
|
||||
|
||||
41
README.md
41
README.md
@ -1,6 +1,7 @@
|
||||
# Community Solid Server
|
||||
|
||||
<img src="https://raw.githubusercontent.com/CommunitySolidServer/CommunitySolidServer/main/templates/images/solid.svg" alt="[Solid logo]" height="150" align="right"/>
|
||||
<img src="https://raw.githubusercontent.com/CommunitySolidServer/CommunitySolidServer/main/templates/images/solid.svg"
|
||||
alt="[Solid logo]" height="150" align="right"/>
|
||||
|
||||
[](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/LICENSE.md)
|
||||
[](https://www.npmjs.com/package/@solid/community-server)
|
||||
@ -30,15 +31,16 @@ And, of course, for many others who like to experience Solid.
|
||||
You can install the software locally or on your server
|
||||
and get started with Solid immediately.
|
||||
|
||||
|
||||
## ⚡ Running the server
|
||||
|
||||
To run the server, you will need [Node.js](https://nodejs.org/en/).
|
||||
We support versions 14.2 and up.
|
||||
<br>
|
||||
|
||||
If you do not use Node.js,
|
||||
you can run a [Docker](https://www.docker.com/) version instead.
|
||||
|
||||
### 💻 Installing and running locally
|
||||
|
||||
After installing Node.js,
|
||||
install the latest server version
|
||||
from the [npm package repository](https://www.npmjs.com/):
|
||||
@ -48,19 +50,23 @@ npm install -g @solid/community-server
|
||||
```
|
||||
|
||||
To run the server with in-memory storage, use:
|
||||
|
||||
```shell
|
||||
community-solid-server # add parameters if needed
|
||||
```
|
||||
|
||||
To run the server with your current folder as storage, use:
|
||||
|
||||
```shell
|
||||
community-solid-server -c @css:config/file.json
|
||||
```
|
||||
|
||||
### 📃 Installing and running from source
|
||||
|
||||
If you rather prefer to run the latest source code version,
|
||||
or if you want to try a specific [branch](https://www.npmjs.com/) of the code,
|
||||
you can use:
|
||||
|
||||
```shell
|
||||
git clone https://github.com/CommunitySolidServer/CommunitySolidServer.git
|
||||
cd CommunitySolidServer
|
||||
@ -69,7 +75,9 @@ npm start -- # add parameters if needed
|
||||
```
|
||||
|
||||
### 📦 Running via Docker
|
||||
Docker allows you to run the server without having Node.js installed. Images are built on each tagged version and hosted on [Docker Hub](https://hub.docker.com/r/solidproject/community-server).
|
||||
|
||||
Docker allows you to run the server without having Node.js installed. Images are built on each tagged version and hosted
|
||||
on [Docker Hub](https://hub.docker.com/r/solidproject/community-server).
|
||||
|
||||
```shell
|
||||
# Clone the repo to get access to the configs
|
||||
@ -86,15 +94,20 @@ docker run --rm -v ~/Solid:/data -p 3000:3000 -it -e CSS_CONFIG=config/file-no-s
|
||||
```
|
||||
|
||||
### 🗃️ Helm Chart
|
||||
The official [Helm](https://helm.sh/) Chart for Kubernetes deployment is maintained at [CommunitySolidServer/css-helm-chart](https://github.com/CommunitySolidServer/css-helm-chart) and published on [ArtifactHUB](https://artifacthub.io/packages/helm/community-solid-server/community-solid-server). There you will find complete installation instructions.
|
||||
|
||||
```
|
||||
The official [Helm](https://helm.sh/) Chart for Kubernetes deployment is maintained at
|
||||
[CommunitySolidServer/css-helm-chart](https://github.com/CommunitySolidServer/css-helm-chart) and published on
|
||||
[ArtifactHUB](https://artifacthub.io/packages/helm/community-solid-server/community-solid-server).
|
||||
There you will find complete installation instructions.
|
||||
|
||||
```shell
|
||||
# Summary
|
||||
helm repo add community-solid-server https://communitysolidserver.github.io/css-helm-chart/charts/
|
||||
helm install my-css community-solid-server/community-solid-server
|
||||
```
|
||||
|
||||
## 🔧 Configuring the server
|
||||
|
||||
The Community Solid Server is designed to be flexible
|
||||
such that people can easily run different configurations.
|
||||
This is useful for customizing the server with plugins,
|
||||
@ -103,6 +116,7 @@ or developing new parts for the server
|
||||
without needing to change its base code.
|
||||
|
||||
### ⏱️ Parameters
|
||||
|
||||
An easy way to customize the server is
|
||||
by passing parameters to the server command.
|
||||
These parameters give you direct access
|
||||
@ -123,7 +137,10 @@ to some commonly used settings:
|
||||
| `--workers, -w` | `1` | Run in multithreaded mode using workers. Special values are `-1` (scale to `num_cores-1`), `0` (scale to `num_cores`) and 1 (singlethreaded). |
|
||||
|
||||
### 🔀 Multithreading
|
||||
The Community Solid Server can be started in multithreaded mode with any config. The config must only contain components that are threadsafe though. If a non-threadsafe component is used in multithreaded mode, the server will describe with an error which class is the culprit.
|
||||
|
||||
The Community Solid Server can be started in multithreaded mode with any config. The config must only contain components
|
||||
that are threadsafe though. If a non-threadsafe component is used in multithreaded mode, the server will describe with
|
||||
an error which class is the culprit.
|
||||
|
||||
```node
|
||||
# Running multithreaded with autoscaling to number of logical cores minus 1
|
||||
@ -131,7 +148,8 @@ npm start -- -c config/file.json -w -1
|
||||
```
|
||||
|
||||
### 🖥️ Environment variables
|
||||
Parameters can also be passed through environment variables.
|
||||
|
||||
Parameters can also be passed through environment variables.
|
||||
|
||||
They are prefixed with `CSS_` and converted from `camelCase` to `CAMEL_CASE`
|
||||
|
||||
@ -140,6 +158,7 @@ They are prefixed with `CSS_` and converted from `camelCase` to `CAMEL_CASE`
|
||||
**Note: command-line arguments will always override environment variables!**
|
||||
|
||||
### 🧶 Custom configurations
|
||||
|
||||
More substantial changes to server behavior can be achieved
|
||||
by writing new configuration files in JSON-LD.
|
||||
The Community Solid Server uses [Components.js](https://componentsjs.readthedocs.io/en/latest/)
|
||||
@ -150,8 +169,8 @@ are available in the [`config` folder](https://github.com/CommunitySolidServer/C
|
||||
|
||||
Recipes for configuring the server can be found at [CommunitySolidServer/recipes](https://github.com/CommunitySolidServer/recipes).
|
||||
|
||||
|
||||
## 👩🏽💻 Developing server code
|
||||
|
||||
The server allows writing and plugging in custom modules
|
||||
without altering its base source code.
|
||||
|
||||
@ -163,8 +182,8 @@ If you want to help out with server development,
|
||||
have a look at the [📓 user documentation](https://communitysolidserver.github.io/CommunitySolidServer/) and
|
||||
[🛠️ good first issues](https://github.com/CommunitySolidServer/CommunitySolidServer/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).
|
||||
|
||||
|
||||
## 📜 License
|
||||
|
||||
The Solid Community Server code
|
||||
is copyrighted by [Inrupt Inc.](https://inrupt.com/)
|
||||
and [imec](https://www.imec-int.com/)
|
||||
@ -177,8 +196,8 @@ Core contributors are
|
||||
and
|
||||
[Matthieu Bosquet](https://github.com/matthieubosquet).
|
||||
|
||||
|
||||
## 🎤 Feedback and questions
|
||||
|
||||
Don't hesitate to [start a discussion](https://github.com/CommunitySolidServer/CommunitySolidServer/discussions)
|
||||
or [report a bug](https://github.com/CommunitySolidServer/CommunitySolidServer/issues).
|
||||
|
||||
|
||||
186
RELEASE_NOTES.md
186
RELEASE_NOTES.md
@ -1,7 +1,9 @@
|
||||
# Community Solid Server release notes
|
||||
|
||||
## v5.0.0
|
||||
|
||||
### New features
|
||||
|
||||
- Metadata of resources can now be edited by PATCHing its description resource.
|
||||
This has an impact on which requests are allowed.
|
||||
See the [documentation](https://communitysolidserver.github.io/CommunitySolidServer/5.x/usage/metadata/) for more information.
|
||||
@ -15,70 +17,76 @@
|
||||
- Support for Node v12 was dropped.
|
||||
|
||||
### Data migration
|
||||
|
||||
No actions are required to migrate data.
|
||||
|
||||
### Configuration changes
|
||||
|
||||
You might need to make changes to your v4 configuration if you use a custom config.
|
||||
|
||||
The `@context` needs to be updated to
|
||||
`https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^5.0.0/components/context.jsonld`.
|
||||
|
||||
The following changes pertain to the imports in the default configs:
|
||||
|
||||
- The prefix of all imports was changed from `files-scs` to `css`.
|
||||
- All default configurations with a file-based backend now use a file-based locker instead of a memory-based one,
|
||||
making them threadsafe.
|
||||
- 2 new options have been added for the `/http/server-factory/` imports: `https-websockets.json` and `https-no-websockets.json`,
|
||||
which allow starting the server with HTTPS by adding 2 new CLI parameters `httpsKey` and `httpsCert`.
|
||||
- `/https-file-cli.json` was greatly simplified because of this change.
|
||||
- `/https-file-cli.json` was greatly simplified because of this change.
|
||||
- `/sparql-file-storage.json` had several changes, simplifying how regexes can be used.
|
||||
|
||||
The following changes are relevant for v4 custom configs that replaced certain features.
|
||||
|
||||
- CLI parsing had several changes.
|
||||
- `/app/variables/*`
|
||||
- `/app/variables/*`
|
||||
- The `SingleThreadedResourceLocker` was renamed.
|
||||
- `/util/resource-locker/memory.json`
|
||||
- `/util/resource-locker/memory.json`
|
||||
- The content-length parser has been moved from the default configuration to the quota configurations.
|
||||
- `/ldp/metadata-parser/default.json`
|
||||
- `/storage/backend/*-quota-file.json`
|
||||
- `/storage/backend/quota/*`
|
||||
- `/ldp/metadata-parser/default.json`
|
||||
- `/storage/backend/*-quota-file.json`
|
||||
- `/storage/backend/quota/*`
|
||||
- Regex routing was updated to use ordered entries.
|
||||
- `/storage/backend/regex.json`
|
||||
- `/storage/backend/regex.json`
|
||||
- The `IdentityProviderFactory` inputs have been extended.
|
||||
- `/identity/handler/provider-factory/identity.json`
|
||||
- `/identity/handler/provider-factory/identity.json`
|
||||
- Restructured the init configs.
|
||||
- `/app/init/*`
|
||||
- `/app/main/default.json`
|
||||
- `/app/init/*`
|
||||
- `/app/main/default.json`
|
||||
- Added lock cleanup on server start.
|
||||
- `/util/resource-locker/file.json`
|
||||
- `/util/resource-locker/redis.json`
|
||||
- `/util/resource-locker/file.json`
|
||||
- `/util/resource-locker/redis.json`
|
||||
- Updated finalizers.
|
||||
- `/app/identity/handler/account-store/default.json`
|
||||
- `/identity/ownership/token.json`
|
||||
- `/ldp/authorization/readers/access-checkers/agent-group.json`
|
||||
- `/ldp/handler/*`
|
||||
- `/app/identity/handler/account-store/default.json`
|
||||
- `/identity/ownership/token.json`
|
||||
- `/ldp/authorization/readers/access-checkers/agent-group.json`
|
||||
- `/ldp/handler/*`
|
||||
- `IntermediateModesExtractor` has been added to the `ModesExtractors`
|
||||
- `/ldp/modes/default.json`
|
||||
- `/ldp/modes/default.json`
|
||||
- The `PermissionReader` structure has changed to be more consistent.
|
||||
- `/ldp/authorization/*`
|
||||
- `/ldp/authorization/*`
|
||||
- Several components now take a `metadataStrategy` parameter to support the new metadata feature.
|
||||
- `/ldp/handler/components/operation-handler.json`
|
||||
- `/storage/backend/*`
|
||||
- Generation of auxiliary link headers was updated.
|
||||
- `/ldp/metadata-writer/writers/link-rel.json`
|
||||
- `/ldp/handler/components/operation-handler.json`
|
||||
- `/storage/backend/*`
|
||||
- Generation of auxiliary link headers was updated.
|
||||
- `/ldp/metadata-writer/writers/link-rel.json`
|
||||
- The `ConstantMetadataWriter` that adds the `MS-Author-Via` header was removed
|
||||
- `/ldp/metadata-writer/default.json`
|
||||
- `/ldp/metadata-writer/default.json`
|
||||
- PATCHing related components were completely refactored.
|
||||
- `/storage/middleware/stores/patching.json`
|
||||
- `/storage/middleware/stores/patching.json`
|
||||
- The metadata auxiliary strategy was added to the default list of auxiliary strategies.
|
||||
- `/util/auxiliary/*`
|
||||
- `/util/auxiliary/*`
|
||||
- Parsing link headers became more flexible.
|
||||
- `/ldp/metadata-parser/parsers/link.json`
|
||||
- `/ldp/metadata-parser/parsers/link.json`
|
||||
|
||||
### Interface changes
|
||||
|
||||
A new interface `SingleThreaded` has been added. This empty interface can be implemented to mark a component as not-threadsafe.
|
||||
When the CSS starts in multithreaded mode, it will error and halt if any SingleThreaded components are instantiated.
|
||||
|
||||
These changes are relevant if you wrote custom modules for the server that depend on existing interfaces.
|
||||
|
||||
- `YargsCliExtractor` was changed to now take as input an array of parameter objects.
|
||||
- `RedirectAllHttpHandler` was removed and fully replaced by `RedirectingHttpHandler`.
|
||||
- `SingleThreadedResourceLocker` has been renamed to `MemoryResourceLocker`.
|
||||
@ -86,10 +94,10 @@ These changes are relevant if you wrote custom modules for the server that depen
|
||||
- The `IdentityProviderFactory` and `ConvertingErrorHandler` now additionally take a `PreferenceParser` as input.
|
||||
- Error handlers now take the incoming `HttpRequest` as input instead of just the preferences.
|
||||
- Extended the initialization/finalization system:
|
||||
* Introduced `Initializable` interface and `InitializableHandler` wrapper class.
|
||||
* Introduced `Finalizer` abstract class and `FinalizableHandler` wrapper class.
|
||||
* Changed type for `finalizer` attribute in `App` from `Finalizable` to `Finalizer` and updated the calling code in `App.stop()`.
|
||||
* Removed the now obsolete `ParallelFinalizer` util class.
|
||||
- Introduced `Initializable` interface and `InitializableHandler` wrapper class.
|
||||
- Introduced `Finalizer` abstract class and `FinalizableHandler` wrapper class.
|
||||
- Changed type for `finalizer` attribute in `App` from `Finalizable` to `Finalizer` and updated the calling code in `App.stop()`.
|
||||
- Removed the now obsolete `ParallelFinalizer` util class.
|
||||
- Added a lock cleanup on initialize for lock implementations `RedisLocker` and `FileSystemResourceLocker`.
|
||||
- `ResourceStore` functions that change a resource now return metadata for every changed resource.
|
||||
- All permission related interfaces have changed to support permissions over multiple identifiers.
|
||||
@ -99,46 +107,56 @@ These changes are relevant if you wrote custom modules for the server that depen
|
||||
- Many patching related classes were changed.
|
||||
|
||||
## v4.1.0
|
||||
|
||||
### New features
|
||||
|
||||
- Environment variables can be used instead of CLI arguments if preferred.
|
||||
|
||||
## v4.0.1
|
||||
|
||||
Freezes the `oidc-provider` dependency to prevent a potential issue with the solid authn client
|
||||
as described in https://github.com/inrupt/solid-client-authn-js/issues/2103.
|
||||
as described in <https://github.com/inrupt/solid-client-authn-js/issues/2103>.
|
||||
|
||||
## v4.0.0
|
||||
|
||||
### New features
|
||||
- The server can be started with a new parameter to automatically generate accounts and pods,
|
||||
|
||||
- The server can be started with a new parameter to automatically generate accounts and pods,
|
||||
for more info see [here](https://communitysolidserver.github.io/CommunitySolidServer/4.x/seeding-pods/).
|
||||
- It is now possible to automate authentication requests using Client Credentials,
|
||||
for more info see [here](https://communitysolidserver.github.io/CommunitySolidServer/4.x/client-credentials/).
|
||||
- A new `RedirectingHttpHandler` class has been added which can be used to redirect certain URLs.
|
||||
- A new default configuration `config/https-file-cli.json`
|
||||
- A new default configuration `config/https-file-cli.json`
|
||||
that can set the HTTPS parameters through the CLI has been added.
|
||||
This is also an example of how to add CLI parameters through a custom configuration.
|
||||
- A new RedisLocker has been added to replace the old RedisResourceLocker class.
|
||||
- A new RedisLocker has been added to replace the old RedisResourceLocker class.
|
||||
It allows for true threadsafe read/write locking.
|
||||
|
||||
### Configuration changes
|
||||
|
||||
You might need to make changes to your v3 configuration if you use a custom config.
|
||||
|
||||
The `@context` needs to be updated to
|
||||
`https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^4.0.0/components/context.jsonld`.
|
||||
|
||||
The following changes pertain to the imports in the default configs:
|
||||
|
||||
- ...
|
||||
|
||||
The following changes are relevant for v3 custom configs that replaced certain features.
|
||||
|
||||
- The key/value storage configs in `config/storage/key-value/*` have been changed to reduce config duplication.
|
||||
All storages there that were only relevant for 1 class have been moved to the config of that class.
|
||||
- Due to a parameter rename in `CombinedSettingsResolver`,
|
||||
- Due to a parameter rename in `CombinedSettingsResolver`,
|
||||
`config/app/variables/resolver/resolver.json` has been updated.
|
||||
- The OIDC provider setup was changed to add client_credentials support.
|
||||
- `/identity/handler/adapter-factory/webid.json`
|
||||
- `/identity/handler/provider-factory/identity.json`
|
||||
- `/identity/handler/adapter-factory/webid.json`
|
||||
- `/identity/handler/provider-factory/identity.json`
|
||||
|
||||
### Interface changes
|
||||
|
||||
These changes are relevant if you wrote custom modules for the server that depend on existing interfaces.
|
||||
|
||||
- The output of `parseContentType` in `HeaderUtil` was changed to include parameters.
|
||||
- `PermissionReader`s take an additional `modes` parameter as input.
|
||||
- The `ResourceStore` function `resourceExists` has been renamed to `hasResource`
|
||||
@ -147,24 +165,27 @@ These changes are relevant if you wrote custom modules for the server that depen
|
||||
- `RepresentationMetadata` no longer accepts strings for predicates in any of its functions.
|
||||
- `CombinedSettingsResolver` parameter `computers` has been renamed to `resolvers`.
|
||||
- `IdentityProviderFactory` requires an additional `credentialStorage` parameter.
|
||||
- The `RedisResourceLocker` class has been removed and the `RedisLocker`class was added instead.
|
||||
- The `RedisResourceLocker` class has been removed and the `RedisLocker`class was added instead.
|
||||
`RedisLocker` implements both the `ResourceLocker` and `ReadWriteLocker` interface.
|
||||
|
||||
## v3.0.0
|
||||
|
||||
### New features
|
||||
|
||||
- The Identity Provider now uses the `webid` scope as required for Solid-OIDC.
|
||||
- The `VoidLocker` can be used to disable locking for development/testing purposes.
|
||||
- The `VoidLocker` can be used to disable locking for development/testing purposes.
|
||||
This can be enabled by changing the `/config/util/resource-locker/` import to `debug-void.json`
|
||||
- Added support for setting a quota on the server. See the `config/quota-file.json` config for an example.
|
||||
- An official docker image is now built on each version tag and published at https://hub.docker.com/r/solidproject/community-server.
|
||||
- An official docker image is now built on each version tag and published at <https://hub.docker.com/r/solidproject/community-server>.
|
||||
- Added support for N3 Patch.
|
||||
- It is now possible to customize arguments to the `community-solid-server` command,
|
||||
- It is now possible to customize arguments to the `community-solid-server` command,
|
||||
which enables passing custom variables to configurations and setting new default values.
|
||||
- The AppRunner functions have changed to require Components.js variables.
|
||||
- The AppRunner functions have changed to require Components.js variables.
|
||||
This is important for anyone who starts the server from code.
|
||||
- When logging in, a consent screen will now provide information about the client.
|
||||
|
||||
### Data migration
|
||||
|
||||
The following actions are required if you are upgrading from a v2 server and want to retain your data.
|
||||
|
||||
Due to changes in the keys used by the IDP, you will need to delete the stored keys and sessions.
|
||||
@ -172,36 +193,43 @@ If you are using a file backend, delete the `.internal/idp/` folder in your data
|
||||
This will not delete the user accounts, but users will have to log in again.
|
||||
|
||||
### Configuration changes
|
||||
|
||||
You might need to make changes to your v2 configuration if you use a custom config.
|
||||
|
||||
The `@context` needs to be updated to
|
||||
The `@context` needs to be updated to
|
||||
`https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^3.0.0/components/context.jsonld`.
|
||||
|
||||
The following changes pertain to the imports in the default configs:
|
||||
|
||||
- A new configuration option needs to be imported:
|
||||
- `/app/variables/default.json` contains everything related to parsing CLI arguments
|
||||
- `/app/variables/default.json` contains everything related to parsing CLI arguments
|
||||
and assigning values to variables.
|
||||
|
||||
The following changes are relevant for v2 custom configs that replaced certain features.
|
||||
|
||||
- Conversion has been simplified so most converters are part of the conversion chain:
|
||||
- `/util/representation-conversion/default.json`
|
||||
- `/util/representation-conversion/default.json`
|
||||
- The IDP settings have changed to support the latest Solid-OIDC draft.
|
||||
- `/identity/handler/provider-factory/identity.json`
|
||||
- `/identity/handler/provider-factory/identity.json`
|
||||
- Requests targeting the OIDC library now use a separate handler.
|
||||
- `/http/handler/default.json`
|
||||
- `/identity/handler/default.json`
|
||||
- `/http/handler/default.json`
|
||||
- `/identity/handler/default.json`
|
||||
- The architecture of IDP interaction handlers has completely changed to improve modularity
|
||||
- `/identity/handler/interaction/*`
|
||||
- `/identity/registration/*`
|
||||
- `/identity/handler/interaction/*`
|
||||
- `/identity/registration/*`
|
||||
|
||||
### Interface changes
|
||||
|
||||
These changes are relevant if you wrote custom modules for the server that depend on existing interfaces.
|
||||
- `TypedRepresentationConverter` function signatures changed
|
||||
|
||||
- `TypedRepresentationConverter` function signatures changed
|
||||
and base functionality moved to `BaseTypedRepresentationConverter`.
|
||||
- Many changes to several components related to the IDP. This includes the HTML templates.
|
||||
|
||||
## v2.0.0
|
||||
|
||||
### New features
|
||||
|
||||
- Pod owners always have Control access to resources stored in their Pod.
|
||||
- The server now offers a one-time setup upon first boot.
|
||||
This can be accessed by going to `/setup`.
|
||||
@ -221,43 +249,51 @@ These changes are relevant if you wrote custom modules for the server that depen
|
||||
E.g., `/idp/register/` works, `/idp/register` will error.
|
||||
|
||||
### Configuration changes
|
||||
|
||||
You might need to make changes to your v1 configuration if you use a custom config.
|
||||
|
||||
The following changes pertain to the imports in the default configs:
|
||||
|
||||
- There are 2 new configuration options that for which a valid option needs to be imported:
|
||||
- `/app/setup` determines how and if setup should be enabled.
|
||||
- `/identity/access` determines if IDP access (e.g., registration) should be restricted
|
||||
- The `/app/init/default.json` configuration no longer initializes the root container.
|
||||
- `/app/setup` determines how and if setup should be enabled.
|
||||
- `/identity/access` determines if IDP access (e.g., registration) should be restricted
|
||||
- The `/app/init/default.json` configuration no longer initializes the root container.
|
||||
This behaviour has been moved to the other options for `/app/init`.
|
||||
- `/ldp/permissions` changed to `/ldp/modes` and only has a default option now.
|
||||
|
||||
The following changes are relevant for v1 custom configs that replaced certain features.
|
||||
The path indicates which JSON-LD files were impacted by the change.
|
||||
- `IdentityProviderHttpHandler` and `InteractionRoute` arguments have changed substantially.
|
||||
- `/identity/handler/default.json`
|
||||
- `/identity/handler/interaction/*`
|
||||
- `/identity/registration/*`.
|
||||
- All internal storage is now stored in the `/.internal/` container.
|
||||
- `/storage/key-value/resource-store.json`.
|
||||
- Patching related classes have changed.
|
||||
- `/storage/middleware/stores/patching.json`.
|
||||
|
||||
- `IdentityProviderHttpHandler` and `InteractionRoute` arguments have changed substantially.
|
||||
- `/identity/handler/default.json`
|
||||
- `/identity/handler/interaction/*`
|
||||
- `/identity/registration/*`.
|
||||
- All internal storage is now stored in the `/.internal/` container.
|
||||
- `/storage/key-value/resource-store.json`.
|
||||
- Patching related classes have changed.
|
||||
- `/storage/middleware/stores/patching.json`.
|
||||
- `BasicRequestParser` now needs a `conditionsParser` argument.
|
||||
- `/ldp/handler/components/request-parser.json`.
|
||||
- `LinkTypeParser` has been renamed to `LinkRelParser` and now takes mappings as input.
|
||||
- `/ldp/metadata-parser/*`
|
||||
- `ComposedAuxiliaryStrategy` `isRootRequired` has been renamed to `requiredInRoot`.
|
||||
- `/util/auxiliary/strategies/acl.json`.
|
||||
- Many changes to authentication and authorization structure.
|
||||
- Config `/ldp/authentication/*` and `/ldp/authorization/*`.
|
||||
- All `HttpHandler`s have been changed.
|
||||
- `/app/setup/handlers/setup.json`
|
||||
- `/http/handler/default.json`
|
||||
- `/identity/handler/default.json`
|
||||
- `/ldp/handler/default.json`.
|
||||
- `/ldp/handler/components/request-parser.json`.
|
||||
- `LinkTypeParser` has been renamed to `LinkRelParser` and now takes mappings as input.
|
||||
- `/ldp/metadata-parser/*`
|
||||
- `ComposedAuxiliaryStrategy` `isRootRequired` has been renamed to `requiredInRoot`.
|
||||
- `/util/auxiliary/strategies/acl.json`.
|
||||
- Many changes to authentication and authorization structure.
|
||||
- Config `/ldp/authentication/*` and `/ldp/authorization/*`.
|
||||
- All `HttpHandler`s have been changed.
|
||||
- `/app/setup/handlers/setup.json`
|
||||
- `/http/handler/default.json`
|
||||
- `/identity/handler/default.json`
|
||||
- `/ldp/handler/default.json`.
|
||||
|
||||
## v1.1.0
|
||||
|
||||
### New features
|
||||
- The `ConstantConverter` can now filter on media type using the `enabledMediaRanges` and `disabledMediaRanges` options. That way, the server can be configured to bypass a default UI when accessing images or PDF documents. (https://github.com/solid/community-server/discussions/895, https://github.com/solid/community-server/pull/925)
|
||||
|
||||
- The `ConstantConverter` can now filter on media type using the `enabledMediaRanges` and `disabledMediaRanges` options.
|
||||
That way, the server can be configured to bypass a default UI when accessing images or PDF documents
|
||||
(<https://github.com/solid/community-server/discussions/895>, <https://github.com/solid/community-server/pull/925>).
|
||||
|
||||
## v1.0.0
|
||||
|
||||
First release of the Community Solid Server.
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
# Configuration
|
||||
|
||||
This folder contains several configurations that can be used to start up the server.
|
||||
All those configurations are created in the same way:
|
||||
features are enabled or disabled by choosing a specific option for every component.
|
||||
@ -8,13 +10,15 @@ Options are then chosen by importing 1 entry from every component subfolder.
|
||||
In case none of the available options have the exact feature configuration you want,
|
||||
it is always possible to not choose any of them and create your own custom version instead.
|
||||
|
||||
# How to use
|
||||
## How to use
|
||||
|
||||
The easiest way to create a new config is by creating a JSON-LD file
|
||||
that imports one option from every component subfolder
|
||||
(such as either `allow-all.json` or `webacl.json` from `ldp/authorization`).
|
||||
In case none of the available options suffice, there are 2 other ways to handle this:
|
||||
|
||||
## Append to an existing config
|
||||
### Append to an existing config
|
||||
|
||||
In case the options mostly suffice, but they just need to do a bit more,
|
||||
it might be possible to append to one of the solutions.
|
||||
|
||||
@ -22,6 +26,7 @@ For example, in case all the existing metadata parsers can remain,
|
||||
but an additional one needs to be added,
|
||||
you could import `ldp/metadata-parser/default.json`
|
||||
and then add the following in your root config:
|
||||
|
||||
```json
|
||||
{
|
||||
"@id": "urn:solid-server:default:MetadataParser",
|
||||
@ -31,6 +36,7 @@ and then add the following in your root config:
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
This will add the new parser to the list of metadata parsers.
|
||||
The `@id` value is needed so Components.js knows which object to add the values to,
|
||||
and the `@type` is needed so it can interpret the other fields (`handlers` in this case).
|
||||
@ -38,13 +44,15 @@ and the `@type` is needed so it can interpret the other fields (`handlers` in th
|
||||
Note that generally it is only advised to append to ParallelHandlers or key/value maps.
|
||||
In case the order is important this can not be guaranteed over separate files.
|
||||
|
||||
## Create a new option
|
||||
### Create a new option
|
||||
|
||||
If a more drastic change is required,
|
||||
the solution is to not import anything from that folder but instead write your own.
|
||||
|
||||
For example, in case you only want the slug parser but not any of the others,
|
||||
you would have to not import anything from `ldp/metadata-parser` folder,
|
||||
but instead have the following in your root config:
|
||||
|
||||
```json
|
||||
{
|
||||
"@id": "urn:solid-server:default:MetadataParser",
|
||||
@ -54,5 +62,6 @@ but instead have the following in your root config:
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Don't forget that in some cases you would also have to copy some imports!
|
||||
The existing options can be used as inspiration.
|
||||
|
||||
@ -1,20 +1,27 @@
|
||||
# App
|
||||
|
||||
Options related to the server startup.
|
||||
|
||||
## Base
|
||||
|
||||
This is the entry point to the main server setup.
|
||||
* *default*: The main application. This should only be changed/replaced
|
||||
|
||||
* *default*: The main application. This should only be changed/replaced
|
||||
if you want to start from a different kind of class.
|
||||
|
||||
## Init
|
||||
|
||||
Contains a list of initializer that need to be run when starting the server.
|
||||
|
||||
* *default*: The default setup. The ParallelHandler can be used to add custom Initializers.
|
||||
* *initialize-root*: Makes sure the root container has the necessary resources to function properly.
|
||||
This is only relevant if setup is disabled but root container access is still required.
|
||||
* *initialize-prefilled-root*: Similar to `initialize-root` but adds some introductory resources to the root container.
|
||||
|
||||
## Setup
|
||||
|
||||
Handles the setup page the first time the server is started.
|
||||
|
||||
* *disabled*: Disables the setup page. Root container access will be impossible unless handled by the Init config above.
|
||||
Registration and pod creation is still possible if that feature is enabled.
|
||||
* *optional*: Setup is available at `/setup` but the server can already be used.
|
||||
@ -22,9 +29,11 @@ Handles the setup page the first time the server is started.
|
||||
* *required*: All requests will be redirected to the setup page until setup is completed.
|
||||
|
||||
## Variables
|
||||
|
||||
Handles parsing CLI parameters and assigning values to Components.js variables.
|
||||
Some parts of the configuration contains variables that can be set as arguments on the command-line.
|
||||
That way, you don't have to edit the configuration files for small changes,
|
||||
That way, you don't have to edit the configuration files for small changes,
|
||||
such as starting the server with a different hostname.
|
||||
Here, you can customize the mapping from CLI arguments into values for those variables.
|
||||
|
||||
* *default*: Assigns CLI parameters for all variables defined in `/config/util/variables/default.json`
|
||||
|
||||
@ -1,19 +1,26 @@
|
||||
# HTTP
|
||||
|
||||
Options related to the base support of HTTP requests by the server.
|
||||
|
||||
## Handler
|
||||
|
||||
Sets up all the handlers a request will potentially pass through.
|
||||
|
||||
* *default*: The full setup, that is middleware + static files + IDP + LDP.
|
||||
* *simple*: A simpler setup in which the IDP is disabled.
|
||||
|
||||
## Middleware
|
||||
|
||||
A set of handlers that will always be run on all requests to add some metadata
|
||||
and then pass the request along.
|
||||
|
||||
* *no-websockets*: The default setup but without the websocket-related metadata.
|
||||
* *websockets*: The default setup with several handlers.
|
||||
|
||||
## Server-Factory
|
||||
|
||||
The factory used to create the actual server object.
|
||||
|
||||
* *no-websockets*: Only HTTP.
|
||||
* *websockets*: HTTP and websockets.
|
||||
* *https-no-websockets*: Only HTTPS. Adds 2 new CLI params to set the key/cert paths.
|
||||
@ -22,6 +29,8 @@ The factory used to create the actual server object.
|
||||
by adding the key/cert paths to the config itself.
|
||||
|
||||
## Static
|
||||
|
||||
Support for static files that should be found at a specific path.
|
||||
|
||||
* *default*: The default handler with a favicon and css for the IDP.
|
||||
New entries can easily be added for new files.
|
||||
|
||||
@ -1,8 +1,11 @@
|
||||
# Identity
|
||||
|
||||
Options related to the Identity Provider.
|
||||
|
||||
## Access
|
||||
|
||||
Determines how publicly accessible some IDP features are.
|
||||
|
||||
* *public*: Everything is publicly accessible.
|
||||
* *restricted*: The IDP components use the same authorization scheme as the main LDP component.
|
||||
For example, if the server uses WebACL authorization and the registration endpoint is `/idp/register/`,
|
||||
@ -12,29 +15,39 @@ Determines how publicly accessible some IDP features are.
|
||||
So make sure to update those two containers so only the correct credentials have the correct rights.
|
||||
|
||||
## Email
|
||||
|
||||
Necessary for sending e-mail when using IDP.
|
||||
|
||||
* *default*: Disables e-mail functionality.
|
||||
* *example*: An example of what your e-mail configuration should look like.
|
||||
In that case you should not import anything from this folder
|
||||
but have the settings in your root config.
|
||||
|
||||
## Handler
|
||||
|
||||
Contains everything needed for setting up the Identity Provider.
|
||||
|
||||
* *default*: As of writing there is not much customization possible.
|
||||
This contains everything needed.
|
||||
|
||||
|
||||
## Ownership
|
||||
|
||||
Which technique to use to determine if a requesting agent owns a WebID.
|
||||
|
||||
* *token*: A token needs to added to the WebID to prove ownership.
|
||||
* *unsafe-no-check*: No verification is done, the agent is always believed.
|
||||
|
||||
## Pod
|
||||
|
||||
What to use for pod creation.
|
||||
|
||||
* *dynamic*: Every created pod has its own Components.js config for its ResourceStore,
|
||||
which can differ from the others.
|
||||
* *static*: All pod data is stored in separate containers in the same ResourceStore.
|
||||
|
||||
## Registration
|
||||
|
||||
If users should be able to register on the server.
|
||||
|
||||
* *enabled*: Enables registration.
|
||||
* *disabled*: Disables registration.
|
||||
|
||||
@ -1,33 +1,46 @@
|
||||
# LDP
|
||||
|
||||
Options related to the Linked Data Platform implementation.
|
||||
This is the core part of the Solid server.
|
||||
|
||||
## Authentication
|
||||
|
||||
Covers how agents are identified.
|
||||
|
||||
* *debug-auth-header*: Allows authentication headers such as `WebID http://test.com/card#me`
|
||||
to identify as that WebID without further checks.
|
||||
* *debug-test-agent*: Always assumes the agent is the set identifier.
|
||||
* *dpop-bearer*: Uses the default DPoP and Bearer identification.
|
||||
|
||||
## Authorization
|
||||
|
||||
Covers how operations are authorized (or rejected).
|
||||
|
||||
* *allow-all*: No authorization, everything is allowed.
|
||||
* *webacl*: Use the default Web Access Control.
|
||||
|
||||
## Handler
|
||||
|
||||
Contains the default LDP handler that will handle most requests.
|
||||
|
||||
* *default*: The default setup.
|
||||
Some identifiers seen here are defined by the other options found in this document.
|
||||
|
||||
## Metadata-Parser
|
||||
|
||||
Contains a list of parsers that will be run on incoming requests to generate metadata.
|
||||
|
||||
* *default*: Contains the default parsers. Can be added to when specific parsers are required.
|
||||
|
||||
## Metadata-Writer
|
||||
|
||||
Contains a list of metadata writers that will be run on outgoing responses.
|
||||
|
||||
* *default*: Contains the default writers. Can be added to when specific parsers are required.
|
||||
|
||||
## Modes
|
||||
|
||||
Determines which modes are needed for requests,
|
||||
by default this is based on the used HTTP method.
|
||||
|
||||
* *default*: Bases required modes on HTTP method.
|
||||
|
||||
@ -1,8 +1,11 @@
|
||||
# Storage
|
||||
|
||||
Options related to how data and resources are stored.
|
||||
|
||||
## Backend
|
||||
|
||||
The final part of the ResourceStore chain that handles data access.
|
||||
|
||||
* *dynamic*: The routing store used here is needed when using dynamic pod creation.
|
||||
* *file*: Default setup with a file backend.
|
||||
* *global-quota-file*: File backend with a global quota over the entire server.
|
||||
@ -13,12 +16,16 @@ The final part of the ResourceStore chain that handles data access.
|
||||
Also updates the converting store so all incoming data is transformed into quads.
|
||||
|
||||
## Key-Value
|
||||
|
||||
Used by certain classes for internal storage.
|
||||
|
||||
* *memory*: Store everything in memory.
|
||||
* *resource-store*: Store everything in a specific container in the resource store.
|
||||
|
||||
## Middleware
|
||||
|
||||
The chain of utility ResourceStores that needs to be passed through before reaching the backend stores.
|
||||
The final store in this chain takes the store from the stores/backend config as source.
|
||||
* *default*: Chains all the utility stores:
|
||||
|
||||
* *default*: Chains all the utility stores:
|
||||
Monitoring -> IndexRepresentation -> Locking -> Patching -> Converting
|
||||
|
||||
@ -1,47 +1,62 @@
|
||||
# Util
|
||||
|
||||
Various utility related options.
|
||||
|
||||
## Auxiliary
|
||||
|
||||
Exports an object that contains a list of all auxiliary resources that need to be supported.
|
||||
In case you create a new auxiliary strategy you can just add it to this list.
|
||||
|
||||
* *acl*: Default list with only support for acl auxiliary resources.
|
||||
* *no-acl*: An empty list which can be added to.
|
||||
|
||||
## Identifiers
|
||||
|
||||
How identifiers should be interpreted.
|
||||
This is mostly relevant when creating pods and/or using a file-based backend.
|
||||
|
||||
* *subdomain*: New pod identifier would be `http://alice.test.com/`.
|
||||
File path of `http://alice.test.com/foo` would be `/alice/foo`.
|
||||
* *suffix*: New pod identifier would be `http://test.com/alice`.
|
||||
Requests to subdomain identifiers would be rejected.
|
||||
|
||||
## Index
|
||||
|
||||
This can be used to provide different behaviour for index files.
|
||||
This is mostly relevant for user interfaces.
|
||||
|
||||
* *default*: No special support.
|
||||
* *example*: An example of how this could be configured.
|
||||
If this is needed the best solution is usually to not import anything here
|
||||
and have the index setup in the root config.
|
||||
|
||||
## Logging
|
||||
|
||||
Which logger to use.
|
||||
|
||||
* *no-logging*: Disables all logging.
|
||||
* *winston*: Uses the winston logger.
|
||||
|
||||
## Representation-conversion
|
||||
|
||||
Used for converting from one content type to another when needed.
|
||||
When a new content type needs to be supported, this can be done by adding a corresponding converter
|
||||
to the ChainedConverter list.
|
||||
|
||||
* *default*: The default conversion setup which supports most RDF formats.
|
||||
|
||||
## Resource-locker
|
||||
|
||||
Which locking mechanism to use to for example prevent 2 write simultaneous write requests.
|
||||
|
||||
* *debug-void*: No locking mechanism, does not prevent simultaneous read/writes.
|
||||
* *file*: Uses a file-system based locking mechanism (process-safe/thread-safe).
|
||||
* *memory*: Uses an in-memory locking mechanism.
|
||||
* *redis*: Uses a Redis store for locking that supports threadsafe read-write locking (process-safe/thread-safe).
|
||||
|
||||
## Variables
|
||||
|
||||
Various variables used by other options.
|
||||
These can usually be set through CLI parameters.
|
||||
|
||||
* *default*: The default list of variables.
|
||||
|
||||
@ -24,26 +24,26 @@ This is a good way to get started with the server and its setup.
|
||||
If you want to know what is new in the latest version,
|
||||
you can check out the [release notes](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/RELEASE_NOTES.md)
|
||||
for a high level overview and information on how to migrate your configuration to the next version.
|
||||
A list that includes all minor changes can be found in
|
||||
A list that includes all minor changes can be found in
|
||||
the [changelog](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/CHANGELOG.md)
|
||||
|
||||
## Using the server
|
||||
|
||||
* [Basic example HTTP requests](usage/example-requests.md)
|
||||
* [Editing the metadata of a resource](usage/metadata.md)
|
||||
* [How to use the Identity Provider](usage/identity-provider.md)
|
||||
* [How to automate authentication](usage/client-credentials.md)
|
||||
* [How to automatically seed pods on startup](usage/seeding-pods.md)
|
||||
* [Basic example HTTP requests](usage/example-requests.md)
|
||||
* [Editing the metadata of a resource](usage/metadata.md)
|
||||
* [How to use the Identity Provider](usage/identity-provider.md)
|
||||
* [How to automate authentication](usage/client-credentials.md)
|
||||
* [How to automatically seed pods on startup](usage/seeding-pods.md)
|
||||
|
||||
## What the internals look like
|
||||
|
||||
* [How the server uses dependency injection](architecture/dependency-injection.md)
|
||||
* [What the architecture looks like](architecture/overview.md)
|
||||
|
||||
* [How the server uses dependency injection](architecture/dependency-injection.md)
|
||||
* [What the architecture looks like](architecture/overview.md)
|
||||
|
||||
## Making changes
|
||||
|
||||
* [How to make changes to the repository](contributing/making-changes.md)
|
||||
* [How to make changes to the repository](contributing/making-changes.md)
|
||||
|
||||
For core developers with push access only:
|
||||
For core developers with push access only:
|
||||
|
||||
* [How to release a new version](contributing/release.md)
|
||||
* [How to release a new version](contributing/release.md)
|
||||
|
||||
@ -4,6 +4,7 @@ There are several core building blocks used in many places of the server.
|
||||
These are described here.
|
||||
|
||||
## Handlers
|
||||
|
||||
A very important building block that gets reused in many places is the `AsyncHandler`.
|
||||
The idea is that a handler has 2 important functions.
|
||||
`canHandle` determines if this class is capable of correctly handling the request,
|
||||
@ -33,6 +34,7 @@ and the `SequenceHandler` that runs all of them one after the other.
|
||||
Since multiple handlers are executed here, these only work for handlers that have no output.
|
||||
|
||||
## Streams
|
||||
|
||||
Almost all data is handled in a streaming fashion.
|
||||
This allows us to work with very large resources without having to fully load them in memory,
|
||||
a client could be reading data that is being returned by the server while the server is still reading the file.
|
||||
|
||||
@ -6,13 +6,14 @@ to link all class instances together,
|
||||
and uses [Components-Generator.js](https://github.com/LinkedSoftwareDependencies/Components-Generator.js)
|
||||
to automatically generate the necessary description configurations of all classes.
|
||||
This framework allows us to configure our components in a JSON file.
|
||||
The advantage of this is that changing the configuration of components does not require any changes to the code,
|
||||
The advantage of this is that changing the configuration of components does not require any changes to the code,
|
||||
as one can just change the default configuration file, or provide a custom configuration file.
|
||||
|
||||
More information can be found in the Components.js [documentation](https://componentsjs.readthedocs.io/),
|
||||
but a summarized overview can be found below.
|
||||
|
||||
## Component files
|
||||
|
||||
Components.js requires a component file for every class you might want to instantiate.
|
||||
Fortunately those get generated automatically by Components-Generator.js.
|
||||
Calling `npm run build` will call the generator and generate those JSON-LD files in the `dist` folder.
|
||||
@ -20,12 +21,14 @@ The generator uses the `index.ts`, so new classes always have to be added there
|
||||
or they will not get a component file.
|
||||
|
||||
## Configuration files
|
||||
|
||||
Configuration files are how we tell Components.js which classes to instantiate and link together.
|
||||
All the community server configurations can be found in
|
||||
the [`config` folder](https://github.com/CommunitySolidServer/CommunitySolidServer/tree/main/config/).
|
||||
That folder also contains information about how different pre-defined configurations can be used.
|
||||
|
||||
A single component in such a configuration file might look as follows:
|
||||
A single component in such a configuration file might look as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
"comment": "Storage used for account management.",
|
||||
@ -38,13 +41,16 @@ A single component in such a configuration file might look as follows:
|
||||
```
|
||||
|
||||
With the corresponding constructor of the `JsonResourceStorage` class:
|
||||
|
||||
```ts
|
||||
public constructor(source: ResourceStore, baseUrl: string, container: string)
|
||||
```
|
||||
|
||||
The important elements here are the following:
|
||||
|
||||
* `"comment"`: _(optional)_ A description of this component.
|
||||
* `"@id"`: _(optional)_ A unique identifier of this component, which allows it to be used as parameter values in different places.
|
||||
* `"@id"`: _(optional)_ A unique identifier of this component, which allows it to be used as parameter values in
|
||||
different places.
|
||||
* `"@type"`: The class name of the component. This must be a TypeScript class name that is exported via `index.ts`.
|
||||
|
||||
As you can see from the constructor, the other fields are direct mappings from the constructor parameters.
|
||||
|
||||
@ -10,7 +10,7 @@ These then get converted into Components.js variables and are used to instantiat
|
||||
flowchart TD
|
||||
CliResolver("<strong>CliResolver</strong><br>CliResolver")
|
||||
CliResolver --> CliResolverArgs
|
||||
|
||||
|
||||
subgraph CliResolverArgs[" "]
|
||||
CliExtractor("<strong>CliExtractor</strong><br>YargsCliExtractor")
|
||||
ShorthandResolver("<strong>ShorthandResolver</strong><br>CombinedShorthandResolver")
|
||||
@ -24,9 +24,9 @@ flowchart TD
|
||||
end
|
||||
```
|
||||
|
||||
The `CliResolver` (`urn:solid-server-app-setup:default:CliResolver`) is simply a way
|
||||
to combine both the `CliExtractor` (`urn:solid-server-app-setup:default:CliExtractor`)
|
||||
and `ShorthandResolver` (`urn:solid-server-app-setup:default:ShorthandResolver`)
|
||||
The `CliResolver` (`urn:solid-server-app-setup:default:CliResolver`) is simply a way
|
||||
to combine both the `CliExtractor` (`urn:solid-server-app-setup:default:CliExtractor`)
|
||||
and `ShorthandResolver` (`urn:solid-server-app-setup:default:ShorthandResolver`)
|
||||
into a single object and has no other function.
|
||||
|
||||
Which arguments are supported and which Components.js variables are generated
|
||||
@ -34,10 +34,12 @@ can depend on the configuration that is being used.
|
||||
For example, for an HTTPS server additional arguments will be needed to specify the necessary key/cert files.
|
||||
|
||||
## CliResolver
|
||||
|
||||
The `CliResolver` converts the incoming string of arguments into a key/value object.
|
||||
By default, a `YargsCliExtractor` is used, which makes use of the `yargs` library and is configured similarly.
|
||||
|
||||
## ShorthandResolver
|
||||
|
||||
The `ShorthandResolver` uses the key/value object that was generated above to generate Components.js variable bindings.
|
||||
A `CombinedShorthandResolver` combines the results of multiple `ShorthandExtractor`
|
||||
by mapping their values to specific variables.
|
||||
|
||||
@ -1,19 +1,21 @@
|
||||
# Handling HTTP requests
|
||||
|
||||
The direction of the arrows was changed slightly here to make the graph readable.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
HttpHandler("<strong>HttpHandler</strong><br>SequenceHandler")
|
||||
HttpHandler --> HttpHandlerArgs
|
||||
|
||||
|
||||
subgraph HttpHandlerArgs[" "]
|
||||
direction LR
|
||||
Middleware("<strong>Middleware</strong><br><i>HttpHandler</i>")
|
||||
WaterfallHandler("<br>WaterfallHandler")
|
||||
end
|
||||
|
||||
|
||||
Middleware --> WaterfallHandler
|
||||
WaterfallHandler --> WaterfallHandlerArgs
|
||||
|
||||
|
||||
subgraph WaterfallHandlerArgs[" "]
|
||||
direction TB
|
||||
StaticAssetHandler("<strong>StaticAssetHandler</strong><br>StaticAssetHandler")
|
||||
@ -23,7 +25,7 @@ flowchart LR
|
||||
IdentityProviderHttpHandler("<strong>IdentityProviderHttpHandler</strong><br><i>HttpHandler</i>")
|
||||
LdpHandler("<strong>LdpHandler</strong><br><i>HttpHandler</i>")
|
||||
end
|
||||
|
||||
|
||||
StaticAssetHandler --> SetupHandler
|
||||
SetupHandler --> OidcHandler
|
||||
OidcHandler --> AuthResourceHttpHandler
|
||||
@ -40,13 +42,15 @@ to find the first handler that understands the request,
|
||||
with the `LdpHandler` at the bottom being the catch-all default.
|
||||
|
||||
## StaticAssetHandler
|
||||
|
||||
The `urn:solid-server:default:StaticAssetHandler` matches exact URLs to static assets which require no further logic.
|
||||
An example of this is the favicon, where the `/favicon.ico` URL
|
||||
An example of this is the favicon, where the `/favicon.ico` URL
|
||||
is directed to the favicon file at `/templates/images/favicon.ico`.
|
||||
It can also map entire folders to a specific path, such as `/.well-known/css/styles/` which contains all stylesheets.
|
||||
|
||||
## SetupHandler
|
||||
The `urn:solid-server:default:SetupHandler` is responsible
|
||||
|
||||
The `urn:solid-server:default:SetupHandler` is responsible
|
||||
for redirecting all requests to `/setup` until setup is finished,
|
||||
thereby ensuring that setup needs to be finished before anything else can be done on the server,
|
||||
and handling the actual setup request that is sent to `/setup`.
|
||||
@ -56,12 +60,14 @@ If the server is configured to not have setup enabled,
|
||||
the corresponding identifier will point to a handler that always rejects all requests.
|
||||
|
||||
## OidcHandler
|
||||
|
||||
The `urn:solid-server:default:OidcHandler` handles all requests related
|
||||
to the Solid-OIDC [specification](https://solid.github.io/solid-oidc/).
|
||||
The OIDC component is configured to work on the `/.oidc/` subpath,
|
||||
so this handler catches all those requests and sends them to the internal OIDC library that is used.
|
||||
|
||||
## AuthResourceHttpHandler
|
||||
|
||||
The `urn:solid-server:default:AuthResourceHttpHandler` is identical
|
||||
to the `urn:solid-server:default:LdpHandler` which will be discussed below,
|
||||
but only handles resources relevant for authorization.
|
||||
@ -75,12 +81,14 @@ to allow authorization on the following handler(s).
|
||||
More on this can be found in the [identity provider](../../../usage/identity-provider/#access) documentation
|
||||
|
||||
## IdentityProviderHttpHandler
|
||||
|
||||
The `urn:solid-server:default:IdentityProviderHttpHandler` handles everything
|
||||
related to our custom identity provider API, such as registering, logging in, returning the relevant HTML pages, etc.
|
||||
All these requests are identified by being on the `/idp/` subpath.
|
||||
More information on the API can be found in the [identity provider](../../../usage/identity-provider) documentation
|
||||
|
||||
## LdpHandler
|
||||
|
||||
Once a request reaches the `urn:solid-server:default:LdpHandler`,
|
||||
the server assumes this is a standard Solid request according to the Solid protocol.
|
||||
A detailed description of what happens then can be found [here](protocol/overview.md)
|
||||
|
||||
@ -6,11 +6,12 @@ Similarly, when stopping the server several Finalizers trigger to clean up where
|
||||
although the latter only happens when starting the server through code.
|
||||
|
||||
## App
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
App("<strong>App</strong><br>App")
|
||||
App --> AppArgs
|
||||
|
||||
|
||||
subgraph AppArgs[" "]
|
||||
Initializer("<strong>Initializer</strong><br><i>Initializer</i>")
|
||||
AppFinalizer("<strong>Finalizer</strong><br><i>Finalizer</i>")
|
||||
@ -24,18 +25,19 @@ It's only function is to contain an `Initializer` and `Finalizer`
|
||||
which get called by calling `start`/`stop` respectively.
|
||||
|
||||
## Initializer
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Initializer("<strong>Initializer</strong><br>SequenceHandler")
|
||||
Initializer --> InitializerArgs
|
||||
|
||||
|
||||
subgraph InitializerArgs[" "]
|
||||
direction LR
|
||||
LoggerInitializer("<strong>LoggerInitializer</strong><br>LoggerInitializer")
|
||||
PrimaryInitializer("<strong>PrimaryInitializer</strong><br>ProcessHandler")
|
||||
WorkerInitializer("<strong>WorkerInitializer</strong><br>ProcessHandler")
|
||||
end
|
||||
|
||||
|
||||
LoggerInitializer --> PrimaryInitializer
|
||||
PrimaryInitializer --> WorkerInitializer
|
||||
```
|
||||
@ -49,26 +51,28 @@ Although if your server setup is single-threaded, which is the default,
|
||||
there is no relevant difference between those two.
|
||||
|
||||
### PrimaryInitializer
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
PrimaryInitializer("<strong>PrimaryInitializer</strong><br>ProcessHandler")
|
||||
PrimaryInitializer --> PrimarySequenceInitializer("<strong>PrimarySequenceInitializer</strong><br>SequenceHandler")
|
||||
PrimarySequenceInitializer --> PrimarySequenceInitializerArgs
|
||||
|
||||
|
||||
subgraph PrimarySequenceInitializerArgs[" "]
|
||||
direction LR
|
||||
CleanupInitializer("<strong>CleanupInitializer</strong><br>SequenceHandler")
|
||||
PrimaryParallelInitializer("<strong>PrimaryParallelInitializer</strong><br>ParallelHandler")
|
||||
WorkerManager("<strong>WorkerManager</strong><br>WorkerManager")
|
||||
end
|
||||
|
||||
|
||||
CleanupInitializer --> PrimaryParallelInitializer
|
||||
PrimaryParallelInitializer --> WorkerManager
|
||||
```
|
||||
|
||||
The above is a simplification of all the initializers that are present in the `PrimaryInitializer`
|
||||
as there are several smaller initializers that also trigger but are less relevant here.
|
||||
|
||||
The `CleanupInitializer` is an initializer that cleans up anything
|
||||
The `CleanupInitializer` is an initializer that cleans up anything
|
||||
that might have remained from a previous server start
|
||||
and could impact behaviour.
|
||||
Relevant components in other parts of the configuration are responsible for adding themselves to this array if needed.
|
||||
@ -80,35 +84,39 @@ This makes it easier for users to add initializers by being able to append to it
|
||||
The `WorkerManager` is responsible for setting up the worker threads, if any.
|
||||
|
||||
### WorkerInitializer
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
WorkerInitializer("<strong>WorkerInitializer</strong><br>ProcessHandler")
|
||||
WorkerInitializer --> WorkerSequenceInitializer("<strong>WorkerSequenceInitializer</strong><br>SequenceHandler")
|
||||
WorkerSequenceInitializer --> WorkerSequenceInitializerArgs
|
||||
|
||||
|
||||
subgraph WorkerSequenceInitializerArgs[" "]
|
||||
direction LR
|
||||
WorkerParallelInitializer("<strong>WorkerParallelInitializer</strong><br>ParallelHandler")
|
||||
ServerInitializer("<strong>ServerInitializer</strong><br>ServerInitializer")
|
||||
end
|
||||
|
||||
|
||||
WorkerParallelInitializer --> ServerInitializer
|
||||
```
|
||||
|
||||
The `WorkerInitializer` is quite similar to the `PrimaryInitializer` but triggers once per worker thread.
|
||||
Like the `PrimaryParallelInitializer`, the `WorkerParallelInitializer` can be used
|
||||
to add any custom initializers that need to run.
|
||||
|
||||
### ServerInitializer
|
||||
|
||||
The `ServerInitializer` is the initializer that finally starts up the server by listening to the relevant port,
|
||||
once all the initialization described above is finished.
|
||||
This is an example of a component that differs based on some of the choices made during configuration.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
ServerInitializer("<strong>ServerInitializer</strong><br>ServerInitializer")
|
||||
ServerInitializer --> WebSocketServerFactory("<strong>ServerFactory</strong><br>WebSocketServerFactory")
|
||||
WebSocketServerFactory --> BaseHttpServerFactory("<br>BaseHttpServerFactory")
|
||||
BaseHttpServerFactory --> HttpHandler("<strong>HttpHandler</strong><br><i>HttpHandler</i>")
|
||||
|
||||
|
||||
ServerInitializer2("<strong>ServerInitializer</strong><br>ServerInitializer")
|
||||
ServerInitializer2 ---> BaseHttpServerFactory2("<strong>ServerFactory</strong><br>BaseHttpServerFactory")
|
||||
BaseHttpServerFactory2 --> HttpHandler2("<strong>HttpHandler</strong><br><i>HttpHandler</i>")
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
flowchart TD
|
||||
AuthorizingHttpHandler("<br>AuthorizingHttpHandler")
|
||||
AuthorizingHttpHandler --> AuthorizingHttpHandlerArgs
|
||||
|
||||
|
||||
subgraph AuthorizingHttpHandlerArgs[" "]
|
||||
CredentialsExtractor("<strong>CredentialsExtractor</strong><br><i>CredentialsExtractor</i>")
|
||||
ModesExtractor("<strong>ModesExtractor</strong><br><i>ModesExtractor</i>")
|
||||
@ -25,6 +25,7 @@ It goes through the following steps:
|
||||
5. If the request is allowed, call the `OperationHttpHandler`, otherwise throw an error.
|
||||
|
||||
## Authentication
|
||||
|
||||
There are multiple `CredentialsExtractor`s that each determine identity in a different way.
|
||||
Potentially multiple extractors can apply,
|
||||
making a requesting agent have multiple credentials.
|
||||
@ -35,12 +36,12 @@ The diagram below shows the default configuration if authentication is enabled.
|
||||
flowchart TD
|
||||
CredentialsExtractor("<strong>CredentialsExtractor</strong><br>UnionCredentialsExtractor")
|
||||
CredentialsExtractor --> CredentialsExtractorArgs
|
||||
|
||||
|
||||
subgraph CredentialsExtractorArgs[" "]
|
||||
WaterfallHandler("<br>WaterfallHandler")
|
||||
PublicCredentialsExtractor("<br>PublicCredentialsExtractor")
|
||||
end
|
||||
|
||||
|
||||
WaterfallHandler --> WaterfallHandlerArgs
|
||||
subgraph WaterfallHandlerArgs[" "]
|
||||
direction LR
|
||||
@ -48,8 +49,8 @@ flowchart TD
|
||||
end
|
||||
```
|
||||
|
||||
Both of the WebID extractors make use of
|
||||
the (`access-token-verifier`)[https://github.com/CommunitySolidServer/access-token-verifier] library
|
||||
Both of the WebID extractors make use of
|
||||
the [`access-token-verifier`](https://github.com/CommunitySolidServer/access-token-verifier) library
|
||||
to parse incoming tokens based on the [Solid-OIDC specification](https://solid.github.io/solid-oidc/).
|
||||
Besides those there are always the public credentials, which everyone has.
|
||||
All these credentials then get combined into a single union object.
|
||||
@ -61,6 +62,7 @@ There are also debug configuration options available that can be used to simulat
|
||||
These can be enabled as different options through the `config/ldp/authentication` imports.
|
||||
|
||||
## Modes extraction
|
||||
|
||||
Access modes are a predefined list of `read`, `write`, `append`, `create` and `delete`.
|
||||
The `ModesExtractor` determine which modes will be necessary and for which resources,
|
||||
based on the request contents.
|
||||
@ -69,9 +71,9 @@ based on the request contents.
|
||||
flowchart TD
|
||||
ModesExtractor("<strong>ModesExtractor</strong><br>IntermediateCreateExtractor")
|
||||
ModesExtractor --> HttpModesExtractor("<strong>HttpModesExtractor</strong><br>WaterfallHandler")
|
||||
|
||||
|
||||
HttpModesExtractor --> HttpModesExtractorArgs
|
||||
|
||||
|
||||
subgraph HttpModesExtractorArgs[" "]
|
||||
direction LR
|
||||
PatchModesExtractor("<strong>PatchModesExtractor</strong><br><i>ModesExtractor</i>") --> MethodModesExtractor("<br>MethodModesExtractor")
|
||||
@ -79,7 +81,8 @@ flowchart TD
|
||||
```
|
||||
|
||||
The `IntermediateCreateExtractor` is responsible if requests try to create intermediate containers with a single request.
|
||||
E.g., a PUT request to `/foo/bar/baz` should create both the `/foo/` and `/foo/bar/` containers in case they do not exist yet.
|
||||
E.g., a PUT request to `/foo/bar/baz` should create both the `/foo/` and `/foo/bar/` containers in case they do not
|
||||
exist yet.
|
||||
This extractor makes sure that `create` permissions are also checked on those containers.
|
||||
|
||||
Modes can usually be determined based on just the HTTP methods,
|
||||
@ -90,7 +93,7 @@ The only exception are PATCH requests,
|
||||
where the necessary modes depend on the body and the PATCH type.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
flowchart TD
|
||||
PatchModesExtractor("<strong>PatchModesExtractor</strong><br>WaterfallHandler") --> PatchModesExtractorArgs
|
||||
subgraph PatchModesExtractorArgs[" "]
|
||||
N3PatchModesExtractor("<br>N3PatchModesExtractor")
|
||||
@ -102,6 +105,7 @@ The server supports both N3 Patch and SPARQL Update PATCH requests.
|
||||
In both cases it will parse the bodies to determine what the impact would be of the request and what modes it requires.
|
||||
|
||||
## Permission reading
|
||||
|
||||
`PermissionReaders` take the input of the above to determine which permissions are available for which credentials.
|
||||
The modes from the previous step are not yet needed,
|
||||
but can be used as optimization as we only need to know if we have permission on those modes.
|
||||
@ -111,17 +115,17 @@ In case authorization is disabled by changing the authorization import to `confi
|
||||
this diagram is just a class that always returns all permissions.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
flowchart TD
|
||||
PermissionReader("<strong>PermissionReader</strong><br>AuxiliaryReader")
|
||||
PermissionReader --> UnionPermissionReader("<br>UnionPermissionReader")
|
||||
UnionPermissionReader --> UnionPermissionReaderArgs
|
||||
|
||||
|
||||
subgraph UnionPermissionReaderArgs[" "]
|
||||
PathBasedReader("<strong>PathBasedReader</strong><br>PathBasedReader")
|
||||
OwnerPermissionReader("<strong>OwnerPermissionReader</strong><br>OwnerPermissionReader")
|
||||
WrappedWebAclReader("<strong>WrappedWebAclReader</strong><br>ParentContainerReader")
|
||||
end
|
||||
|
||||
|
||||
WrappedWebAclReader --> WebAclAuxiliaryReader("<strong>WebAclAuxiliaryReader</strong><br>WebAclAuxiliaryReader")
|
||||
WebAclAuxiliaryReader --> WebAclReader("<strong>WebAclReader</strong><br>WebAclReader")
|
||||
```
|
||||
@ -136,7 +140,7 @@ If one reader rejects a specific mode and another allows it, the rejection takes
|
||||
The `PathBasedReader` rejects all permissions for certain paths.
|
||||
This is used to prevent access to the internal data of the server.
|
||||
|
||||
The `OwnerPermissionReader` makes sure owners always have control access
|
||||
The `OwnerPermissionReader` makes sure owners always have control access
|
||||
to the [pods they created on the server](../../../../usage/identity-provider/#pod).
|
||||
Users will always be able to modify the ACL resources in their pod,
|
||||
even if they accidentally removed their own access.
|
||||
@ -150,12 +154,13 @@ In case the target is an ACL resource, `control` permissions need to be checked,
|
||||
no matter what mode was generated by the `ModesExtractor`.
|
||||
The `WebAclAuxiliaryReader` makes sure this conversion happens.
|
||||
|
||||
Finally, the `WebAclReader` implements
|
||||
Finally, the `WebAclReader` implements
|
||||
the [efffective ACL resource algorithm](https://solidproject.org/TR/2021/wac-20210711#effective-acl-resource)
|
||||
and returns the permissions it finds in that resource.
|
||||
In case no ACL resource is found this indicates a configuration error and no permissions will be granted.
|
||||
|
||||
## Authorization
|
||||
|
||||
All the results of the previous steps then get combined in the `PermissionBasedAuthorizer` to either allow or reject a request.
|
||||
If no permissions are found for a requested mode,
|
||||
or they are explicitly forbidden,
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
# Solid protocol
|
||||
|
||||
The `LdpHandler`, named as a reference to the Linked Data Platform specification,
|
||||
chains several handlers together, each with their own specific purpose, to fully resolve the HTTP request.
|
||||
It specifically handles Solid requests as described
|
||||
|
||||
@ -1,9 +1,10 @@
|
||||
# Parsing and responding to HTTP requests
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
ParsingHttphandler("<br>ParsingHttphandler")
|
||||
ParsingHttphandler --> ParsingHttphandlerArgs
|
||||
|
||||
|
||||
subgraph ParsingHttphandlerArgs[" "]
|
||||
RequestParser("<strong>RequestParser</strong><br>BasicRequestParser")
|
||||
AuthorizingHttpHandler("<strong></strong><br>AuthorizingHttpHandler")
|
||||
@ -17,11 +18,12 @@ It follows these 3 steps:
|
||||
|
||||
1. Use the `RequestParser` to convert the incoming data into an `Operation`.
|
||||
2. Send the `Operation` to the `AuthorizingHttpHandler` to receive either a `Representation` if the operation was a success,
|
||||
or an `Error` in case something went wrong.
|
||||
* In case of an error the `ErrorHandler` will convert the `Error` into a `ResponseDescription`.
|
||||
or an `Error` in case something went wrong.
|
||||
* In case of an error the `ErrorHandler` will convert the `Error` into a `ResponseDescription`.
|
||||
3. Use the `ResponseWriter` to output the `ResponseDescription` as an HTTP response.
|
||||
|
||||
## Parsing the request
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RequestParser("<strong>RequestParser</strong><br>BasicRequestParser") --> RequestParserArgs
|
||||
@ -32,12 +34,14 @@ flowchart TD
|
||||
BodyParser("<br><i>Bodyparser</i>")
|
||||
Conditions("<br>BasicConditionsParser")
|
||||
end
|
||||
|
||||
|
||||
OriginalUrlExtractor --> IdentifierStrategy("<strong>IdentifierStrategy</strong><br><i>IdentifierStrategy</i>")
|
||||
```
|
||||
|
||||
The `BasicRequestParser` is mostly an aggregator of multiple smaller parsers that each handle a very specific part.
|
||||
|
||||
### URL
|
||||
|
||||
This is a single class, the `OriginalUrlExtractor`, but fulfills the very important role
|
||||
of making sure input URLs are handled consistently.
|
||||
|
||||
@ -53,14 +57,16 @@ This can differ depending on if the server uses subdomains or not.
|
||||
The resulting identifier will be stored in the `target` field of an `Operation` object.
|
||||
|
||||
### Preferences
|
||||
|
||||
The `AcceptPreferenceParser` parses the `Accept` header and all the relevant `Accept-*` headers.
|
||||
These will all be put into the `preferences` field of an `Operation` object.
|
||||
These will later be used to handle the content negotiation.
|
||||
|
||||
For example, when sending an `Accept: text/turtle; q=0.9` header,
|
||||
For example, when sending an `Accept: text/turtle; q=0.9` header,
|
||||
this wil result in the preferences object `{ type: { 'text/turtle': 0.9 } }`.
|
||||
|
||||
### Headers
|
||||
|
||||
Several other headers can have relevant metadata,
|
||||
such as the `Content-Type` header,
|
||||
or the `Link: <http://www.w3.org/ns/ldp#Container>; rel="type"` header
|
||||
@ -73,6 +79,7 @@ The default `MetadataParser` is a `ParallelHandler` that contains several smalle
|
||||
each looking at a specific header.
|
||||
|
||||
### Body
|
||||
|
||||
In case of most requests, the input data stream is used directly in the `body` field of the `Operation`,
|
||||
with a few minor checks to make sure the HTTP specification is being followed.
|
||||
|
||||
@ -82,19 +89,21 @@ into a JavaScript object containing all the necessary information to execute suc
|
||||
Several validation checks will already take place there as well.
|
||||
|
||||
### Conditions
|
||||
|
||||
The `BasicConditionsParser` parses everything related to conditions headers,
|
||||
such as `if-none-match` or `if-modified-since`,
|
||||
and stores the relevant information in the `conditions` field of the `Operation`.
|
||||
These will later be used to make sure the request should be aborted or not.
|
||||
|
||||
## Sending the response
|
||||
|
||||
In case a request is successful, the `AuthorizingHttpHandler` will return a `ResponseDescription`,
|
||||
and if not it will throw an error.
|
||||
|
||||
In case an error gets thrown, this will be caught by the `ErrorHandler` and converted into a `ResponseDescription`.
|
||||
The request preferences will be used to make sure the serialization is one that is preferred.
|
||||
|
||||
Either way we will have a `ResponseDescription`,
|
||||
Either way we will have a `ResponseDescription`,
|
||||
which will be sent to the `BasicResponseWriter` to convert into output headers, data and a status code.
|
||||
|
||||
To convert the metadata into headers, it uses a `MetadataWriter`,
|
||||
|
||||
@ -1,11 +1,12 @@
|
||||
# Resource store
|
||||
|
||||
The interface of a `ResourceStore` is mostly a 1-to-1 mapping of the HTTP methods:
|
||||
|
||||
* GET: `getRepresentation`
|
||||
* PUT: `setRepresentation`
|
||||
* POST: `addResource`
|
||||
* DELETE: `deleteResource`
|
||||
* PATCH: `modifyResource`
|
||||
* GET: `getRepresentation`
|
||||
* PUT: `setRepresentation`
|
||||
* POST: `addResource`
|
||||
* DELETE: `deleteResource`
|
||||
* PATCH: `modifyResource`
|
||||
|
||||
The corresponding `OperationHandler` of the relevant method
|
||||
is responsible for calling the correct `ResourceStore` function.
|
||||
@ -14,36 +15,41 @@ In practice, the community server has multiple resource stores chained together,
|
||||
each handling a specific part of the request and then calling the next store in the chain.
|
||||
The default configurations come with the following stores:
|
||||
|
||||
1. `MonitoringStore`
|
||||
2. `IndexRepresentationStore`
|
||||
3. `LockingResourceStore`
|
||||
4. `PatchingStore`
|
||||
5. `RepresentationConvertingStore`
|
||||
6. `DataAccessorBasedStore`
|
||||
1. `MonitoringStore`
|
||||
2. `IndexRepresentationStore`
|
||||
3. `LockingResourceStore`
|
||||
4. `PatchingStore`
|
||||
5. `RepresentationConvertingStore`
|
||||
6. `DataAccessorBasedStore`
|
||||
|
||||
This chain can be seen in the configuration part in `config/storage/middleware/default.json`
|
||||
and all the entries in `config/storage/backend`.
|
||||
|
||||
## MonitoringStore
|
||||
|
||||
This store emits the events that are necessary to emit notifications when resources change.
|
||||
|
||||
There are 4 different events that can be emitted:
|
||||
- `this.emit('changed', identifier, activity)`: is emitted for every resource that was changed/effected by a call to the store.
|
||||
With activity being undefined or one of the available ActivityStream terms.
|
||||
- `this.emit(AS.Create, identifier)`: is emitted for every resource that was created by the call to the store.
|
||||
- `this.emit(AS.Update, identifier)`: is emitted for every resource that was updated by the call to the store.
|
||||
- `this.emit(AS.Delete, identifier)`: is emitted for every resource that was deleted by the call to the store.
|
||||
|
||||
* `this.emit('changed', identifier, activity)`: is emitted for every resource that was changed/effected by a
|
||||
call to the store.
|
||||
With activity being undefined or one of the available ActivityStream terms.
|
||||
* `this.emit(AS.Create, identifier)`: is emitted for every resource that was created by the call to the store.
|
||||
* `this.emit(AS.Update, identifier)`: is emitted for every resource that was updated by the call to the store.
|
||||
* `this.emit(AS.Delete, identifier)`: is emitted for every resource that was deleted by the call to the store.
|
||||
|
||||
A `changed` event will always be emitted if a resource was changed.
|
||||
If the correct metadata was set by the source `ResourceStore`, an additional field will be sent along indicating the type of change,
|
||||
and an additional corresponding event will be emitted, depending on what the change is.
|
||||
If the correct metadata was set by the source `ResourceStore`, an additional field will be sent along indicating the
|
||||
type of change, and an additional corresponding event will be emitted, depending on what the change is.
|
||||
|
||||
## IndexRepresentationStore
|
||||
|
||||
When doing a GET request on a container `/container/`,
|
||||
this container returns the contents of `/container/index.html` instead if HTML is the preferred response type.
|
||||
All these values are the defaults and can be configured for other resources and media types.
|
||||
|
||||
## LockingResourceStore
|
||||
|
||||
To prevent data corruption, the server locks resources when being targeted by a request.
|
||||
Locks are only released when an operation is completely finished,
|
||||
in the case of read operations this means the entire data stream is read,
|
||||
@ -53,6 +59,7 @@ This allows simultaneous read requests on the same resource,
|
||||
but only while no write request is in progress.
|
||||
|
||||
## PatchingStore
|
||||
|
||||
PATCH operations in Solid apply certain transformations on the target resource,
|
||||
which makes them more complicated than only reading or writing data since it involves both.
|
||||
The `PatchingStore` provides a generic solution for backends that do not implement the `modifyResource` function
|
||||
@ -63,6 +70,7 @@ apply the transformation on that data,
|
||||
and then PUT it back to the store.
|
||||
|
||||
## RepresentationConvertingStore
|
||||
|
||||
This store handles everything related to content negotiation.
|
||||
In case the resulting data of a GET request does not match the preferences of a request,
|
||||
it will be converted here.
|
||||
@ -71,14 +79,13 @@ the SPARQL backend only accepts triples for example,
|
||||
that is also handled here
|
||||
|
||||
## DataAccessorBasedStore
|
||||
|
||||
Large parts of the requirements of the Solid protocol specification are resolved by the `DataAccessorBasedStore`:
|
||||
POST only working on containers,
|
||||
DELETE not working on non-empty containers,
|
||||
POST only working on containers, DELETE not working on non-empty containers,
|
||||
generating `ldp:contains` triples for containers, etc.
|
||||
Most of this behaviour is independent of how the data is stored which is why it can be generalized here.
|
||||
The store's name comes from the fact that it makes use of `DataAccessor`s to handle the read/write of resources.
|
||||
A `DataAccessor` is a simple interface that only focuses on handling the data.
|
||||
It does not concern itself with any of the necessary Solid checks as it assumes those have already been made.
|
||||
This means that if a storage method needs to be supported,
|
||||
only a new `DataAccessor` needs to be made,
|
||||
This means that if a storage method needs to be supported, only a new `DataAccessor` needs to be made,
|
||||
after which it can be plugged into the rest of the server.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Architecture overview
|
||||
|
||||
The initial architecture document the project was started from can be found
|
||||
The initial architecture document the project was started from can be found
|
||||
[here](https://rubenverborgh.github.io/solid-server-architecture/solid-architecture-v1-3-0.pdf).
|
||||
Many things have been added since the original inception of the project,
|
||||
but the core ideas within that document are still valid.
|
||||
@ -26,7 +26,7 @@ We will use an example below to explain the formatting used throughout the archi
|
||||
flowchart TD
|
||||
LdpHandler("<strong>LdpHandler</strong><br>ParsingHttphandler")
|
||||
LdpHandler --> LdpHandlerArgs
|
||||
|
||||
|
||||
subgraph LdpHandlerArgs[" "]
|
||||
RequestParser("<strong>RequestParser</strong><br>BasicRequestParser")
|
||||
Auth("<br>AuthorizingHttpHandler")
|
||||
@ -38,14 +38,14 @@ flowchart TD
|
||||
Below is a summary of how to interpret such diagrams:
|
||||
|
||||
* Rounded red box: component instantiated in the Components.js [configuration](dependency-injection.md).
|
||||
* First line:
|
||||
* **Bold text**: shorthand of the instance identifier. In case the full URI is not specified,
|
||||
it can usually be found by prepending `urn:solid-server:default:` to the shorthand identifier.
|
||||
* (empty): this instance has no identifier and is defined in the same place as its parent.
|
||||
* Second line:
|
||||
* Regular text: The class of this instance.
|
||||
* _Italic text_: The interface of this instance.
|
||||
Will be used if the actual class is not relevant for the explanation or can differ.
|
||||
* First line:
|
||||
* **Bold text**: shorthand of the instance identifier. In case the full URI is not specified,
|
||||
it can usually be found by prepending `urn:solid-server:default:` to the shorthand identifier.
|
||||
* (empty): this instance has no identifier and is defined in the same place as its parent.
|
||||
* Second line:
|
||||
* Regular text: The class of this instance.
|
||||
* _Italic text_: The interface of this instance.
|
||||
Will be used if the actual class is not relevant for the explanation or can differ.
|
||||
* Square grey box: the parameters of the linked instance.
|
||||
* Arrow: links an instance to its parameters. Can also be used to indicate the order of parameters if relevant.
|
||||
|
||||
@ -53,7 +53,8 @@ For example, in the above, **LdpHandler** is a shorthand for the actual identifi
|
||||
and is an instance of `ParsingHttpHandler`. It has 4 parameters,
|
||||
one of which has no identifier but is an instance of `AuthorizingHttpHandler`.
|
||||
|
||||
# Features
|
||||
## Features
|
||||
|
||||
Below are the sections that go deeper into the features of the server and how those work.
|
||||
|
||||
* [How Command Line Arguments are parsed and used](features/cli.md)
|
||||
|
||||
@ -1,25 +1,26 @@
|
||||
# Pull requests
|
||||
|
||||
The community server is fully written in [Typescript](https://www.typescriptlang.org/docs/home.html).
|
||||
|
||||
All changes should be done through
|
||||
[pull requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork).
|
||||
[pull requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork).
|
||||
|
||||
We recommend first discussing a possible solution in the relevant issue
|
||||
to reduce the amount of changes that will be requested.
|
||||
|
||||
In case any of your changes are breaking, make sure you target the next major branch (`versions/x.0.0`)
|
||||
instead of the main branch. Breaking changes include: changing interface/class signatures,
|
||||
potentially breaking external custom configurations,
|
||||
potentially breaking external custom configurations,
|
||||
and breaking how internal data is stored.
|
||||
In case of doubt you probably want to target the next major branch.
|
||||
|
||||
We make use of [Conventional Commits](https://www.conventionalcommits.org).
|
||||
|
||||
Don't forget to update the [release notes](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/RELEASE_NOTES.md)
|
||||
Don't forget to update the [release notes](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/RELEASE_NOTES.md)
|
||||
when adding new major features.
|
||||
Also update any relevant documentation in case this is needed.
|
||||
|
||||
When making changes to a pull request,
|
||||
When making changes to a pull request,
|
||||
we prefer to update the existing commits with a rebase instead of appending new commits,
|
||||
this way the PR can be rebased directly onto the target branch
|
||||
instead of needing to be squashed.
|
||||
@ -28,6 +29,6 @@ There are strict requirements from the linter and the test coverage before a PR
|
||||
These are configured to run automatically when trying to commit to git.
|
||||
Although there are no tests for it (yet), we strongly advice documenting with [TSdoc](https://github.com/microsoft/tsdoc).
|
||||
|
||||
If a list of entries is alphabetically sorted,
|
||||
If a list of entries is alphabetically sorted,
|
||||
such as [index.ts](https://github.com/CommunitySolidServer/CommunitySolidServer/blob/main/src/index.ts),
|
||||
make sure it stays that way.
|
||||
|
||||
@ -12,12 +12,16 @@ Steps to follow:
|
||||
* None of the above has to be blocking per se, but should be noted in the release notes if relevant.
|
||||
* Verify that the `RELEASE_NOTES.md` are correct.
|
||||
* `npm run release -- -r major`
|
||||
* Automatically updates Components.js references to the new version. Committed with `chore(release): Update configs to vx.0.0`.
|
||||
* Updates the `package.json`, and generates the new entries in `CHANGELOG.md`. Commited with `chore(release): Release version vx.0.0 of the npm package`
|
||||
* Optionally run `npx commit-and-tag-version -r major --dry-run` to preview the commands that will be run and the changes to `CHANGELOG.md`.
|
||||
* Automatically updates Components.js references to the new version.
|
||||
Committed with `chore(release): Update configs to vx.0.0`.
|
||||
* Updates the `package.json`, and generates the new entries in `CHANGELOG.md`.
|
||||
Commited with `chore(release): Release version vx.0.0 of the npm package`
|
||||
* Optionally run `npx commit-and-tag-version -r major --dry-run` to preview the commands that will be run
|
||||
and the changes to `CHANGELOG.md`.
|
||||
* The `postrelease` script will now prompt you to manually edit the `CHANGELOG.md`.
|
||||
* All entries are added in separate sections of the new release according to their commit prefixes.
|
||||
* Re-organize the entries accordingly, referencing previous releases. Most of the entries in Chores and Documentation can be removed.
|
||||
* Re-organize the entries accordingly, referencing previous releases. Most of the entries in Chores and
|
||||
Documentation can be removed.
|
||||
* Press any key in your terminal when your changes are ready.
|
||||
* The `postrelease` script will amend the release commit, create an annotated tag and push changes to origin.
|
||||
* Merge `versions/x.0.0` into `main` and push.
|
||||
|
||||
@ -11,7 +11,7 @@ This is a temporary solution until the server has more advanced account manageme
|
||||
after which this API will change.
|
||||
|
||||
Below is example code of how to make use of these tokens.
|
||||
It makes use of several utility functions from the
|
||||
It makes use of several utility functions from the
|
||||
[Solid Authentication Client](https://github.com/inrupt/solid-client-authn-js).
|
||||
Note that the code below uses top-level `await`, which not all JavaScript engines support,
|
||||
so this should all be contained in an `async` function.
|
||||
@ -72,7 +72,7 @@ const response = await fetch(tokenUrl, {
|
||||
});
|
||||
|
||||
// This is the Access token that will be used to do an authenticated request to the server.
|
||||
// The JSON also contains an "expires_in" field in seconds,
|
||||
// The JSON also contains an "expires_in" field in seconds,
|
||||
// which you can use to know when you need request a new Access token.
|
||||
const { access_token: accessToken } = await response.json();
|
||||
```
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
## Interacting with the server
|
||||
# Interacting with the server
|
||||
|
||||
### `PUT`: Creating resources for a given URL
|
||||
## `PUT`: Creating resources for a given URL
|
||||
|
||||
Create a plain text file:
|
||||
|
||||
```shell
|
||||
curl -X PUT -H "Content-Type: text/plain" \
|
||||
-d "abc" \
|
||||
@ -10,15 +11,17 @@ curl -X PUT -H "Content-Type: text/plain" \
|
||||
```
|
||||
|
||||
Create a turtle file:
|
||||
|
||||
```shell
|
||||
curl -X PUT -H "Content-Type: text/turtle" \
|
||||
-d "<ex:s> <ex:p> <ex:o>." \
|
||||
http://localhost:3000/myfile.ttl
|
||||
```
|
||||
|
||||
### `POST`: Creating resources at a generated URL
|
||||
## `POST`: Creating resources at a generated URL
|
||||
|
||||
Create a plain text file:
|
||||
|
||||
```shell
|
||||
curl -X POST -H "Content-Type: text/plain" \
|
||||
-d "abc" \
|
||||
@ -26,6 +29,7 @@ curl -X POST -H "Content-Type: text/plain" \
|
||||
```
|
||||
|
||||
Create a turtle file:
|
||||
|
||||
```shell
|
||||
curl -X POST -H "Content-Type: text/turtle" \
|
||||
-d "<ex:s> <ex:p> <ex:o>." \
|
||||
@ -34,33 +38,36 @@ curl -X POST -H "Content-Type: text/turtle" \
|
||||
|
||||
The response's `Location` header will contain the URL of the created resource.
|
||||
|
||||
### `GET`: Retrieving resources
|
||||
## `GET`: Retrieving resources
|
||||
|
||||
Retrieve a plain text file:
|
||||
|
||||
```shell
|
||||
curl -H "Accept: text/plain" \
|
||||
http://localhost:3000/myfile.txt
|
||||
```
|
||||
|
||||
Retrieve a turtle file:
|
||||
|
||||
```shell
|
||||
curl -H "Accept: text/turtle" \
|
||||
http://localhost:3000/myfile.ttl
|
||||
```
|
||||
|
||||
Retrieve a turtle file in a different serialization:
|
||||
|
||||
```shell
|
||||
curl -H "Accept: application/ld+json" \
|
||||
http://localhost:3000/myfile.ttl
|
||||
```
|
||||
|
||||
### `DELETE`: Deleting resources
|
||||
## `DELETE`: Deleting resources
|
||||
|
||||
```shell
|
||||
curl -X DELETE http://localhost:3000/myfile.txt
|
||||
```
|
||||
|
||||
### `PATCH`: Modifying resources
|
||||
## `PATCH`: Modifying resources
|
||||
|
||||
Modify a resource using [N3 Patch](https://solidproject.org/TR/protocol#n3-patch):
|
||||
|
||||
@ -78,16 +85,15 @@ curl -X PATCH -H "Content-Type: application/sparql-update" \
|
||||
http://localhost:3000/myfile.ttl
|
||||
```
|
||||
|
||||
### `HEAD`: Retrieve resources headers
|
||||
## `HEAD`: Retrieve resources headers
|
||||
|
||||
```shell
|
||||
curl -I -H "Accept: text/plain" \
|
||||
http://localhost:3000/myfile.txt
|
||||
```
|
||||
|
||||
### `OPTIONS`: Retrieve resources communication options
|
||||
## `OPTIONS`: Retrieve resources communication options
|
||||
|
||||
```shell
|
||||
curl -X OPTIONS -i http://localhost:3000/myfile.txt
|
||||
```
|
||||
|
||||
|
||||
@ -4,22 +4,24 @@ Besides implementing the [Solid protocol](https://solidproject.org/TR/protocol),
|
||||
the community server can also be an Identity Provider (IDP), officially known as an OpenID Provider (OP),
|
||||
following the [Solid OIDC spec](https://solid.github.io/solid-oidc/) as much as possible.
|
||||
|
||||
It is recommended to use the latest version
|
||||
It is recommended to use the latest version
|
||||
of the [Solid authentication client](https://github.com/inrupt/solid-client-authn-js)
|
||||
to interact with the server.
|
||||
|
||||
The links here assume the server is hosted at `http://localhost:3000/`.
|
||||
|
||||
## Registering an account
|
||||
|
||||
To register an account, you can go to `http://localhost:3000/idp/register/` if this feature is enabled,
|
||||
which it is on all configurations we provide.
|
||||
Currently our registration page ties 3 features together on the same page:
|
||||
|
||||
* Creating an account on the server.
|
||||
* Creating or linking a WebID to your account.
|
||||
* Creating a pod on the server.
|
||||
* Creating an account on the server.
|
||||
* Creating or linking a WebID to your account.
|
||||
* Creating a pod on the server.
|
||||
|
||||
### Account
|
||||
|
||||
To create an account you need to provide an email address and password.
|
||||
The password will be salted and hashed before being stored.
|
||||
As of now, the account is only used to log in and identify yourself to the IDP
|
||||
@ -27,12 +29,13 @@ when you want to do an authenticated request,
|
||||
but in future the plan is to also use this for account/pod management.
|
||||
|
||||
### WebID
|
||||
|
||||
We require each account to have a corresponding WebID.
|
||||
You can either let the server create a WebID for you in a pod,
|
||||
which will also need to be created then,
|
||||
or you can link an already existing WebID you have on an external server.
|
||||
|
||||
In case you try to link your own WebID, you can choose if you want to be able
|
||||
In case you try to link your own WebID, you can choose if you want to be able
|
||||
to use this server as your IDP for this WebID.
|
||||
If not, you can still create a pod,
|
||||
but you will not be able to direct the authentication client to this server to identify yourself.
|
||||
@ -47,6 +50,7 @@ that you have to add an additional triple to your WebID if you want to use the s
|
||||
All of the above is automated if you create the WebID on the server itself.
|
||||
|
||||
### Pod
|
||||
|
||||
To create a pod you simply have to fill in the name you want your pod to have.
|
||||
This will then be used to generate the full URL of your pod.
|
||||
For example, if you choose the name `test`,
|
||||
@ -54,11 +58,12 @@ your pod would be located at `http://localhost:3000/test/`
|
||||
and your generated WebID would be `http://localhost:3000/test/profile/card#me`.
|
||||
|
||||
The generated name also depends on the configuration you chose for your server.
|
||||
If you are using the subdomain feature,
|
||||
If you are using the subdomain feature,
|
||||
such as being done in the `config/memory-subdomains.json` configuration,
|
||||
the generated pod URL would be `http://test.localhost:3000/`.
|
||||
|
||||
## Logging in
|
||||
|
||||
When using an authenticating client,
|
||||
you will be redirected to a login screen asking for your email and password.
|
||||
After that you will be redirected to a page showing some basic information about the client.
|
||||
@ -67,12 +72,14 @@ As a result the server will send a token back to the client
|
||||
that contains all the information needed to use your WebID.
|
||||
|
||||
## Forgot password
|
||||
|
||||
If you forgot your password, you can recover it by going to `http://localhost:3000/idp/forgotpassword/`.
|
||||
There you can enter your email address to get a recovery mail to reset your password.
|
||||
This feature only works if a mail server was configured,
|
||||
which by default is not the case.
|
||||
|
||||
## JSON API
|
||||
|
||||
All of the above happens through HTML pages provided by the server.
|
||||
By default, the server uses the templates found in `/templates/identity/email-password/`
|
||||
but different templates can be used through configuration.
|
||||
@ -80,6 +87,7 @@ but different templates can be used through configuration.
|
||||
These templates all make use of a JSON API exposed by the server.
|
||||
For example, when doing a GET request to `http://localhost:3000/idp/register/`
|
||||
with a JSON accept header, the following JSON is returned:
|
||||
|
||||
```json
|
||||
{
|
||||
"required": {
|
||||
@ -106,9 +114,11 @@ with a JSON accept header, the following JSON is returned:
|
||||
"apiVersion": "0.3"
|
||||
}
|
||||
```
|
||||
|
||||
The `required` and `optional` fields indicate which input fields are expected by the API.
|
||||
These correspond to the fields of the HTML registration page.
|
||||
To register a user, you can do a POST request with a JSON body containing the correct fields:
|
||||
|
||||
```json
|
||||
{
|
||||
"email": "test@example.com",
|
||||
@ -121,6 +131,7 @@ To register a user, you can do a POST request with a JSON body containing the co
|
||||
"podName": "test"
|
||||
}
|
||||
```
|
||||
|
||||
Two fields here that are not covered on the HTML page above are `rootPod` and `template`.
|
||||
`rootPod` tells the server to put the pod in the root of the server instead of a location based on the `podName`.
|
||||
By default the server will reject requests where this is `true`, except during setup.
|
||||
@ -129,15 +140,17 @@ which is a very custom setup where every pod can have a different Components.js
|
||||
so this value can usually be ignored.
|
||||
|
||||
## IDP configuration
|
||||
|
||||
The above descriptions cover server behaviour with most default configurations,
|
||||
but just like any other feature, there are several features that can be changed
|
||||
through the imports in your configuration file.
|
||||
|
||||
All available options can be found in
|
||||
All available options can be found in
|
||||
the [`config/identity/` folder](https://github.com/CommunitySolidServer/CommunitySolidServer/tree/main/config/identity).
|
||||
Below we go a bit deeper into the available options
|
||||
|
||||
### access
|
||||
|
||||
The `access` option allows you to set authorization restrictions on the IDP API when enabled,
|
||||
similar to how authorization works on the LDP requests on the server.
|
||||
For example, if the server uses WebACL as authorization scheme,
|
||||
@ -151,16 +164,19 @@ All of the above is only relevant if you use the `restricted.json` setting for t
|
||||
When you use `public.json` the API will simply always be accessible by everyone.
|
||||
|
||||
### email
|
||||
|
||||
In case you want users to be able to reset their password when they forget it,
|
||||
you will need to tell the server which email server to use to send reset mails.
|
||||
`example.json` contains an example of what this looks like,
|
||||
which you will need to copy over to your base configuration and then remove the `config/identity/email` import.
|
||||
|
||||
### handler
|
||||
|
||||
There is only one option here. This import contains all the core components necessary to make the IDP work.
|
||||
In case you need to make some changes to core IDP settings, this is where you would have to look.
|
||||
|
||||
### pod
|
||||
|
||||
The `pod` options determines how pods are created. `static.json` is the expected pod behaviour as described above.
|
||||
`dynamic.json` is an experimental feature that allows users
|
||||
to have a custom Components.js configuration for their own pod.
|
||||
@ -168,6 +184,7 @@ When using such a setup, a JSON file will be written containing all the informat
|
||||
so they can be recreated when the server restarts.
|
||||
|
||||
### registration
|
||||
|
||||
This setting allows you to enable/disable registration on the server.
|
||||
Disabling registration here does not disable registration during setup,
|
||||
meaning you can still use this server as an IDP with the account created there.
|
||||
|
||||
@ -20,7 +20,7 @@ has `http://example.org/resource.meta` as its description resource.
|
||||
## How to edit the metadata of a resource
|
||||
|
||||
Editing the metadata of a resource is performed by editing the description resource directly.
|
||||
This can only be done using `PATCH` requests
|
||||
This can only be done using `PATCH` requests
|
||||
(see [example workflow](#example-of-a-workflow-for-editing-a-description-resource)).
|
||||
|
||||
`PUT` requests on description resources are not allowed,
|
||||
@ -38,17 +38,18 @@ The CSS will throw an error (409 `ConflictHttpError`) when trying to change this
|
||||
|
||||
### Preserving metadata
|
||||
|
||||
`PUT` requests on a resource will reset the description resource.
|
||||
`PUT` requests on a resource will reset the description resource.
|
||||
There is however a way to keep the contents of description resource prior to the `PUT` request:
|
||||
adding the HTTP `Link` header targeting the description resource with `rel="preserve"`.
|
||||
|
||||
When the resource URL is `http://localhost:3000/foobar`, preserving its description resource when updating its contents can be achieved like in the following example:
|
||||
When the resource URL is `http://localhost:3000/foobar`, preserving its description resource when updating its contents
|
||||
can be achieved like in the following example:
|
||||
|
||||
```shell
|
||||
curl -X PUT 'http://localhost:3000/foobar' \
|
||||
-H 'Content-Type: text/turtle' \
|
||||
-H 'Link: <http://localhost:3000/foobar.meta>;rel="preserve"' \
|
||||
-d "<ex:s> <ex:p> <ex:o>."
|
||||
-d "<ex:s> <ex:p> <ex:o>."
|
||||
```
|
||||
|
||||
## Impact on creating containers
|
||||
@ -80,6 +81,7 @@ which will produce a response with at least these headers:
|
||||
HTTP/1.1 200 OK
|
||||
Link: <http://localhost:3000/foo/.meta>; rel="describedby"
|
||||
```
|
||||
|
||||
Now that we have the URL of the description resource,
|
||||
we create a patch for adding the inbox in the description of the resource.
|
||||
|
||||
@ -96,7 +98,9 @@ After this update, we can verify that the inbox is added by performing a GET req
|
||||
```shell
|
||||
curl 'http://localhost:3000/foo/.meta'
|
||||
```
|
||||
|
||||
With as result for the body
|
||||
|
||||
```turtle
|
||||
@prefix dc: <http://purl.org/dc/terms/>.
|
||||
@prefix ldp: <http://www.w3.org/ns/ldp#>.
|
||||
|
||||
@ -1,12 +1,13 @@
|
||||
# How to seed Accounts and Pods
|
||||
|
||||
If you need to seed accounts and pods,
|
||||
If you need to seed accounts and pods,
|
||||
the `--seededPodConfigJson` command line option can be used
|
||||
with as value the path to a JSON file containing configurations for every required pod.
|
||||
The file needs to contain an array of JSON objects,
|
||||
with each object containing at least a `podName`, `email`, and `password` field.
|
||||
The file needs to contain an array of JSON objects,
|
||||
with each object containing at least a `podName`, `email`, and `password` field.
|
||||
|
||||
For example:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
@ -17,10 +18,11 @@ For example:
|
||||
]
|
||||
```
|
||||
|
||||
You may optionally specify other parameters
|
||||
You may optionally specify other parameters
|
||||
as described in the [Identity Provider documentation](identity-provider.md#json-api).
|
||||
|
||||
For example, to set up a pod without registering the generated WebID with the Identity Provider:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
|
||||
276
package-lock.json
generated
276
package-lock.json
generated
@ -101,6 +101,7 @@
|
||||
"husky": "^4.3.8",
|
||||
"jest": "^27.5.1",
|
||||
"jest-rdf": "^1.7.0",
|
||||
"markdownlint-cli2": "^0.5.1",
|
||||
"node-mocks-http": "^1.11.0",
|
||||
"nodemon": "^2.0.19",
|
||||
"set-cookie-parser": "^2.5.1",
|
||||
@ -11310,6 +11311,15 @@
|
||||
"integrity": "sha1-HADHQ7QzzQpOgHWPe2SldEDZ/wA=",
|
||||
"dev": true
|
||||
},
|
||||
"node_modules/linkify-it": {
|
||||
"version": "4.0.1",
|
||||
"resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz",
|
||||
"integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"uc.micro": "^1.0.1"
|
||||
}
|
||||
},
|
||||
"node_modules/load-json-file": {
|
||||
"version": "4.0.0",
|
||||
"resolved": "https://registry.npmjs.org/load-json-file/-/load-json-file-4.0.0.tgz",
|
||||
@ -11507,6 +11517,123 @@
|
||||
"node": ">=8"
|
||||
}
|
||||
},
|
||||
"node_modules/markdown-it": {
|
||||
"version": "13.0.1",
|
||||
"resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz",
|
||||
"integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"argparse": "^2.0.1",
|
||||
"entities": "~3.0.1",
|
||||
"linkify-it": "^4.0.1",
|
||||
"mdurl": "^1.0.1",
|
||||
"uc.micro": "^1.0.5"
|
||||
},
|
||||
"bin": {
|
||||
"markdown-it": "bin/markdown-it.js"
|
||||
}
|
||||
},
|
||||
"node_modules/markdown-it/node_modules/argparse": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
|
||||
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
|
||||
"dev": true
|
||||
},
|
||||
"node_modules/markdownlint": {
|
||||
"version": "0.26.2",
|
||||
"resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz",
|
||||
"integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"markdown-it": "13.0.1"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=14"
|
||||
}
|
||||
},
|
||||
"node_modules/markdownlint-cli2": {
|
||||
"version": "0.5.1",
|
||||
"resolved": "https://registry.npmjs.org/markdownlint-cli2/-/markdownlint-cli2-0.5.1.tgz",
|
||||
"integrity": "sha512-f3Nb1GF/c8YSrV/FntsCWzpa5mLFJRlO+wzEgv+lkNQjU6MZflUwc2FbyEDPTo6oVhP2VyUOkK0GkFgfuktl1w==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"globby": "13.1.2",
|
||||
"markdownlint": "0.26.2",
|
||||
"markdownlint-cli2-formatter-default": "0.0.3",
|
||||
"micromatch": "4.0.5",
|
||||
"strip-json-comments": "5.0.0",
|
||||
"yaml": "2.1.1"
|
||||
},
|
||||
"bin": {
|
||||
"markdownlint-cli2": "markdownlint-cli2.js",
|
||||
"markdownlint-cli2-config": "markdownlint-cli2-config.js",
|
||||
"markdownlint-cli2-fix": "markdownlint-cli2-fix.js"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=14"
|
||||
}
|
||||
},
|
||||
"node_modules/markdownlint-cli2-formatter-default": {
|
||||
"version": "0.0.3",
|
||||
"resolved": "https://registry.npmjs.org/markdownlint-cli2-formatter-default/-/markdownlint-cli2-formatter-default-0.0.3.tgz",
|
||||
"integrity": "sha512-QEAJitT5eqX1SNboOD+SO/LNBpu4P4je8JlR02ug2cLQAqmIhh8IJnSK7AcaHBHhNADqdGydnPpQOpsNcEEqCw==",
|
||||
"dev": true,
|
||||
"peerDependencies": {
|
||||
"markdownlint-cli2": ">=0.0.4"
|
||||
}
|
||||
},
|
||||
"node_modules/markdownlint-cli2/node_modules/globby": {
|
||||
"version": "13.1.2",
|
||||
"resolved": "https://registry.npmjs.org/globby/-/globby-13.1.2.tgz",
|
||||
"integrity": "sha512-LKSDZXToac40u8Q1PQtZihbNdTYSNMuWe+K5l+oa6KgDzSvVrHXlJy40hUP522RjAIoNLJYBJi7ow+rbFpIhHQ==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"dir-glob": "^3.0.1",
|
||||
"fast-glob": "^3.2.11",
|
||||
"ignore": "^5.2.0",
|
||||
"merge2": "^1.4.1",
|
||||
"slash": "^4.0.0"
|
||||
},
|
||||
"engines": {
|
||||
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
|
||||
},
|
||||
"funding": {
|
||||
"url": "https://github.com/sponsors/sindresorhus"
|
||||
}
|
||||
},
|
||||
"node_modules/markdownlint-cli2/node_modules/slash": {
|
||||
"version": "4.0.0",
|
||||
"resolved": "https://registry.npmjs.org/slash/-/slash-4.0.0.tgz",
|
||||
"integrity": "sha512-3dOsAHXXUkQTpOYcoAxLIorMTp4gIQr5IW3iVb7A7lFIp0VHhnynm9izx6TssdrIcVIESAlVjtnO2K8bg+Coew==",
|
||||
"dev": true,
|
||||
"engines": {
|
||||
"node": ">=12"
|
||||
},
|
||||
"funding": {
|
||||
"url": "https://github.com/sponsors/sindresorhus"
|
||||
}
|
||||
},
|
||||
"node_modules/markdownlint-cli2/node_modules/strip-json-comments": {
|
||||
"version": "5.0.0",
|
||||
"resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-5.0.0.tgz",
|
||||
"integrity": "sha512-V1LGY4UUo0jgwC+ELQ2BNWfPa17TIuwBLg+j1AA/9RPzKINl1lhxVEu2r+ZTTO8aetIsUzE5Qj6LMSBkoGYKKw==",
|
||||
"dev": true,
|
||||
"engines": {
|
||||
"node": ">=14.16"
|
||||
},
|
||||
"funding": {
|
||||
"url": "https://github.com/sponsors/sindresorhus"
|
||||
}
|
||||
},
|
||||
"node_modules/markdownlint-cli2/node_modules/yaml": {
|
||||
"version": "2.1.1",
|
||||
"resolved": "https://registry.npmjs.org/yaml/-/yaml-2.1.1.tgz",
|
||||
"integrity": "sha512-o96x3OPo8GjWeSLF+wOAbrPfhFOGY0W00GNaxCDv+9hkcDJEnev1yh8S7pgHF0ik6zc8sQLuL8hjHjJULZp8bw==",
|
||||
"dev": true,
|
||||
"engines": {
|
||||
"node": ">= 14"
|
||||
}
|
||||
},
|
||||
"node_modules/marked": {
|
||||
"version": "4.0.18",
|
||||
"resolved": "https://registry.npmjs.org/marked/-/marked-4.0.18.tgz",
|
||||
@ -11518,6 +11645,12 @@
|
||||
"node": ">= 12"
|
||||
}
|
||||
},
|
||||
"node_modules/mdurl": {
|
||||
"version": "1.0.1",
|
||||
"resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz",
|
||||
"integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==",
|
||||
"dev": true
|
||||
},
|
||||
"node_modules/media-typer": {
|
||||
"version": "0.3.0",
|
||||
"resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz",
|
||||
@ -11658,13 +11791,13 @@
|
||||
}
|
||||
},
|
||||
"node_modules/micromatch": {
|
||||
"version": "4.0.4",
|
||||
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.4.tgz",
|
||||
"integrity": "sha512-pRmzw/XUcwXGpD9aI9q/0XOwLNygjETJ8y0ao0wdqprrzDa4YnxLcz7fQRZr8voh8V10kGhABbNcHVk5wHgWwg==",
|
||||
"version": "4.0.5",
|
||||
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz",
|
||||
"integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==",
|
||||
"dev": true,
|
||||
"dependencies": {
|
||||
"braces": "^3.0.1",
|
||||
"picomatch": "^2.2.3"
|
||||
"braces": "^3.0.2",
|
||||
"picomatch": "^2.3.1"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=8.6"
|
||||
@ -12561,9 +12694,9 @@
|
||||
"dev": true
|
||||
},
|
||||
"node_modules/picomatch": {
|
||||
"version": "2.3.0",
|
||||
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.0.tgz",
|
||||
"integrity": "sha512-lY1Q/PiJGC2zOv/z391WOTD+Z02bCgsFfvxoXXf6h7kv9o+WmsmzYqrAwY63sNgOxE4xEdq0WyUnXfKeBrSvYw==",
|
||||
"version": "2.3.1",
|
||||
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
|
||||
"integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
|
||||
"dev": true,
|
||||
"engines": {
|
||||
"node": ">=8.6"
|
||||
@ -14562,6 +14695,12 @@
|
||||
"node": ">=4.2.0"
|
||||
}
|
||||
},
|
||||
"node_modules/uc.micro": {
|
||||
"version": "1.0.6",
|
||||
"resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz",
|
||||
"integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==",
|
||||
"dev": true
|
||||
},
|
||||
"node_modules/uglify-js": {
|
||||
"version": "3.12.0",
|
||||
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-3.12.0.tgz",
|
||||
@ -24120,6 +24259,15 @@
|
||||
"integrity": "sha1-HADHQ7QzzQpOgHWPe2SldEDZ/wA=",
|
||||
"dev": true
|
||||
},
|
||||
"linkify-it": {
|
||||
"version": "4.0.1",
|
||||
"resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz",
|
||||
"integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==",
|
||||
"dev": true,
|
||||
"requires": {
|
||||
"uc.micro": "^1.0.1"
|
||||
}
|
||||
},
|
||||
"load-json-file": {
|
||||
"version": "4.0.0",
|
||||
"resolved": "https://registry.npmjs.org/load-json-file/-/load-json-file-4.0.0.tgz",
|
||||
@ -24290,11 +24438,101 @@
|
||||
"integrity": "sha512-glc9y00wgtwcDmp7GaE/0b0OnxpNJsVf3ael/An6Fe2Q51LLwN1er6sdomLRzz5h0+yMpiYLhWYF5R7HeqVd4g==",
|
||||
"dev": true
|
||||
},
|
||||
"markdown-it": {
|
||||
"version": "13.0.1",
|
||||
"resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz",
|
||||
"integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==",
|
||||
"dev": true,
|
||||
"requires": {
|
||||
"argparse": "^2.0.1",
|
||||
"entities": "~3.0.1",
|
||||
"linkify-it": "^4.0.1",
|
||||
"mdurl": "^1.0.1",
|
||||
"uc.micro": "^1.0.5"
|
||||
},
|
||||
"dependencies": {
|
||||
"argparse": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
|
||||
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
|
||||
"dev": true
|
||||
}
|
||||
}
|
||||
},
|
||||
"markdownlint": {
|
||||
"version": "0.26.2",
|
||||
"resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz",
|
||||
"integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==",
|
||||
"dev": true,
|
||||
"requires": {
|
||||
"markdown-it": "13.0.1"
|
||||
}
|
||||
},
|
||||
"markdownlint-cli2": {
|
||||
"version": "0.5.1",
|
||||
"resolved": "https://registry.npmjs.org/markdownlint-cli2/-/markdownlint-cli2-0.5.1.tgz",
|
||||
"integrity": "sha512-f3Nb1GF/c8YSrV/FntsCWzpa5mLFJRlO+wzEgv+lkNQjU6MZflUwc2FbyEDPTo6oVhP2VyUOkK0GkFgfuktl1w==",
|
||||
"dev": true,
|
||||
"requires": {
|
||||
"globby": "13.1.2",
|
||||
"markdownlint": "0.26.2",
|
||||
"markdownlint-cli2-formatter-default": "0.0.3",
|
||||
"micromatch": "4.0.5",
|
||||
"strip-json-comments": "5.0.0",
|
||||
"yaml": "2.1.1"
|
||||
},
|
||||
"dependencies": {
|
||||
"globby": {
|
||||
"version": "13.1.2",
|
||||
"resolved": "https://registry.npmjs.org/globby/-/globby-13.1.2.tgz",
|
||||
"integrity": "sha512-LKSDZXToac40u8Q1PQtZihbNdTYSNMuWe+K5l+oa6KgDzSvVrHXlJy40hUP522RjAIoNLJYBJi7ow+rbFpIhHQ==",
|
||||
"dev": true,
|
||||
"requires": {
|
||||
"dir-glob": "^3.0.1",
|
||||
"fast-glob": "^3.2.11",
|
||||
"ignore": "^5.2.0",
|
||||
"merge2": "^1.4.1",
|
||||
"slash": "^4.0.0"
|
||||
}
|
||||
},
|
||||
"slash": {
|
||||
"version": "4.0.0",
|
||||
"resolved": "https://registry.npmjs.org/slash/-/slash-4.0.0.tgz",
|
||||
"integrity": "sha512-3dOsAHXXUkQTpOYcoAxLIorMTp4gIQr5IW3iVb7A7lFIp0VHhnynm9izx6TssdrIcVIESAlVjtnO2K8bg+Coew==",
|
||||
"dev": true
|
||||
},
|
||||
"strip-json-comments": {
|
||||
"version": "5.0.0",
|
||||
"resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-5.0.0.tgz",
|
||||
"integrity": "sha512-V1LGY4UUo0jgwC+ELQ2BNWfPa17TIuwBLg+j1AA/9RPzKINl1lhxVEu2r+ZTTO8aetIsUzE5Qj6LMSBkoGYKKw==",
|
||||
"dev": true
|
||||
},
|
||||
"yaml": {
|
||||
"version": "2.1.1",
|
||||
"resolved": "https://registry.npmjs.org/yaml/-/yaml-2.1.1.tgz",
|
||||
"integrity": "sha512-o96x3OPo8GjWeSLF+wOAbrPfhFOGY0W00GNaxCDv+9hkcDJEnev1yh8S7pgHF0ik6zc8sQLuL8hjHjJULZp8bw==",
|
||||
"dev": true
|
||||
}
|
||||
}
|
||||
},
|
||||
"markdownlint-cli2-formatter-default": {
|
||||
"version": "0.0.3",
|
||||
"resolved": "https://registry.npmjs.org/markdownlint-cli2-formatter-default/-/markdownlint-cli2-formatter-default-0.0.3.tgz",
|
||||
"integrity": "sha512-QEAJitT5eqX1SNboOD+SO/LNBpu4P4je8JlR02ug2cLQAqmIhh8IJnSK7AcaHBHhNADqdGydnPpQOpsNcEEqCw==",
|
||||
"dev": true,
|
||||
"requires": {}
|
||||
},
|
||||
"marked": {
|
||||
"version": "4.0.18",
|
||||
"resolved": "https://registry.npmjs.org/marked/-/marked-4.0.18.tgz",
|
||||
"integrity": "sha512-wbLDJ7Zh0sqA0Vdg6aqlbT+yPxqLblpAZh1mK2+AO2twQkPywvvqQNfEPVwSSRjZ7dZcdeVBIAgiO7MMp3Dszw=="
|
||||
},
|
||||
"mdurl": {
|
||||
"version": "1.0.1",
|
||||
"resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz",
|
||||
"integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==",
|
||||
"dev": true
|
||||
},
|
||||
"media-typer": {
|
||||
"version": "0.3.0",
|
||||
"resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz",
|
||||
@ -24402,13 +24640,13 @@
|
||||
}
|
||||
},
|
||||
"micromatch": {
|
||||
"version": "4.0.4",
|
||||
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.4.tgz",
|
||||
"integrity": "sha512-pRmzw/XUcwXGpD9aI9q/0XOwLNygjETJ8y0ao0wdqprrzDa4YnxLcz7fQRZr8voh8V10kGhABbNcHVk5wHgWwg==",
|
||||
"version": "4.0.5",
|
||||
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz",
|
||||
"integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==",
|
||||
"dev": true,
|
||||
"requires": {
|
||||
"braces": "^3.0.1",
|
||||
"picomatch": "^2.2.3"
|
||||
"braces": "^3.0.2",
|
||||
"picomatch": "^2.3.1"
|
||||
}
|
||||
},
|
||||
"mime": {
|
||||
@ -25054,9 +25292,9 @@
|
||||
"dev": true
|
||||
},
|
||||
"picomatch": {
|
||||
"version": "2.3.0",
|
||||
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.0.tgz",
|
||||
"integrity": "sha512-lY1Q/PiJGC2zOv/z391WOTD+Z02bCgsFfvxoXXf6h7kv9o+WmsmzYqrAwY63sNgOxE4xEdq0WyUnXfKeBrSvYw==",
|
||||
"version": "2.3.1",
|
||||
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
|
||||
"integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
|
||||
"dev": true
|
||||
},
|
||||
"pify": {
|
||||
@ -26615,6 +26853,12 @@
|
||||
"integrity": "sha512-C0WQT0gezHuw6AdY1M2jxUO83Rjf0HP7Sk1DtXj6j1EwkQNZrHAg2XPWlq62oqEhYvONq5pkC2Y9oPljWToLmQ==",
|
||||
"dev": true
|
||||
},
|
||||
"uc.micro": {
|
||||
"version": "1.0.6",
|
||||
"resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz",
|
||||
"integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==",
|
||||
"dev": true
|
||||
},
|
||||
"uglify-js": {
|
||||
"version": "3.12.0",
|
||||
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-3.12.0.tgz",
|
||||
|
||||
@ -55,7 +55,10 @@
|
||||
"docker:stop": "./test/docker/docker-stop.sh",
|
||||
"typedocs": "typedoc --customCss ./documentation/typedoc.css",
|
||||
"jest": "jest --coverageReporters text-summary --",
|
||||
"lint": "eslint . --cache --ignore-path .gitignore --max-warnings 0",
|
||||
"lint": "npm run lint:ts && npm run lint:markdown",
|
||||
"lint:ts": "eslint . --cache --ignore-path .gitignore --max-warnings 0",
|
||||
"lint:markdown": "markdownlint-cli2",
|
||||
"lint:markdown:fix": "markdownlint-cli2-fix",
|
||||
"prepare": "npm run build",
|
||||
"release": "commit-and-tag-version",
|
||||
"postrelease": "ts-node ./scripts/finalizeRelease.ts",
|
||||
@ -171,6 +174,7 @@
|
||||
"@typescript-eslint/eslint-plugin": "^5.3.0",
|
||||
"@typescript-eslint/parser": "^5.3.0",
|
||||
"cheerio": "^1.0.0-rc.12",
|
||||
"commit-and-tag-version": "^10.1.0",
|
||||
"componentsjs-generator": "^3.0.3",
|
||||
"eslint": "^8.21.0",
|
||||
"eslint-config-es": "4.1.0",
|
||||
@ -184,6 +188,7 @@
|
||||
"husky": "^4.3.8",
|
||||
"jest": "^27.5.1",
|
||||
"jest-rdf": "^1.7.0",
|
||||
"markdownlint-cli2": "^0.5.1",
|
||||
"node-mocks-http": "^1.11.0",
|
||||
"nodemon": "^2.0.19",
|
||||
"set-cookie-parser": "^2.5.1",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user