
* Add identity provider handler as a dependency * Temp Identity * Figured out how to get koa to work * Hooked up idp to networking * Feat/idp architecture refactor (#430) * Logs in with solid oidc * Refactored Provider * Attempt to hook up dependencies * Partial wiring of oidc provider components * IdP networking now works with architecture * Interaction Handlers Set Up * fix: Rename & adapt to CSS * Included Login Interaction * Refactored architecture to bind Interaction Policy to HttpHandlers Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com> * fix: Rebase on master * fix: DI after rebase * Reimplemented Routing * Renamed modules and removed ProviderFactory (#450) * refactor: Solid IdP DI * refactor: IdP interaction handler DI * refactor: IdP interaction waterfall * refactor: Remove unnecessary legacy URL parse * fix: Add legacy parse back in * feat: adapter & fix: handlers * Removed adapter factory * fix: refactor IdP * fix: refactor IdP * fix: refactor IdP * feat: Add IdP to file storage config * fix: Unintended commit * fix: Components ignore * feat: Basic resource store adapter * Partially complete idp routing * Set up initial routing injection graph * Clean up ResourceStorageAdapter * Refactored configuration architecture * Hooked up Login UIs (#518) * feat: Use template path & run fileserver * feat: Use util function to read resource * Fixed DI JSON-LD context * fixed rendering * WebId validator * Set up persistent storage for loing and register * Fixed ejs template routing * Refactored StorageAdapters * NSS login successful * Forgot password infrastructure * Can send email (#557) * Can send email * fix: IdP crashes if interaction ID doesn't exist (#587) * feat: Require an issuer registration token * fix: Issuer registration token typo in error * fix: Remove dummy IdP storage adapter * fix: Remove unused library lodash * fix: Remove unused library lru-cache * Production ready keystore * Ruben comments before clownface removal * Removed clownface * Change key value store * Completed Ruben's comments * Added comments to each class * Fixed errors on login * Ruben feedback * Refactored out getPostRenderHandler * Identity provider tests (#622) * corrected tests lacking <void> on promises * Added files for all idp tests * Added unfinished tests for all added files * ErrorHandlingWaterfallHandler * RenderEjsHandler and RouterHandler tests * GetPostRouterHandler and BasicOnErrorHandler tests * Corrected tests for updates to Idp * fix: missing export * fix: audience claim * Client Id Support (#630) * Added client_id for the auth challenge * Update src/identity/storage/ClientWebIdFetchingStorageAdapterFactory.ts Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com> Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com> * fix: Rebase fixes * Several minor Idp changes/refactors (#656) * fix: Minor changes * refactor: Split EmailPasswordInteractionPolicy * refactor: Remove ErrorHandlingWaterfallHandler * refactor: Clean up dependencies * fix: Add dummy IdentityProviderHandler to fix integration tests * Replace KeyValueStore with KeyValueStorage (#663) * feat: Create WrappedExpiringStorage * refactor: Update ResourceStoreEmailPasswordStore to use KeyValueStorage * refactor: Update KeyGeneratingIdpConfigurationGenerator to use KeyValueStorage * refactor: Update ResourceStoreStorageAdapterFactory to use ExpiringStorage * refactor: Removed KeyValueStore * refactor: Simplify EmailPassword handlers (#664) * refactor: Order index.ts * test: Add EmailPasswordForgotPasswordHandler unit tests * test: Add EmailPasswordGetResetPasswordHandler unit tests * test: Add EmailPasswordLoginHandler unit tests * test: Add EmailPasswordRegistrationHandler unit tests * test: Add EmailPasswordResetPasswordHandler unit tests * test: Remove unnecessary test file * feat: Basic instructions for using the IdP * fix: IdP instructions and add example WebID * fix: IdP registration copy * fix: IdP instruction editorial * Update README.md Co-authored-by: Joachim Van Herwegen <joachimvh@gmail.com> * Update README.md Co-authored-by: Joachim Van Herwegen <joachimvh@gmail.com> * test: Add KeyGeneratingIdpConfigurationGenerator unit tests * test: Add KeyValueEmailPasswordStore unit tests * test: Create IdP integration test * test: Add EmailPasswordInteractionPolicy unit tests * test: Add BasicIssuerReferenceWebIdOwnershipValidator unit tests * test: Add ChooseInitialInteractionHandler unit tests Also fixes the config warning. * test: Add EjsTemplateRenderer unit tests * test: Add EmailSender unit tests * test: Add FormDataUtil unit tests * test: Add IdpRouteController unit tests * test: Add OidcInteractionCompleter unit tests * refactor: Simplify ClientWebIdFetchingStorageAdapterFactory * test: Add ClientWebIdFetchingStorageAdapterFactory unit tests * refactor: Fix ejs html warnings * test: Add step to test logging in again Included are updates to handle cookies more correctly. * feat: Add IdpConfirmHttpHandler This way there's a handler for the confirm page. * test: Add ExpiringStorageAdapterFactory unit tests * test: Add IdentityProviderFactory unit tests * test: Add IdentityProviderHttpHandler unit tests * refactor: Minor refactors * refactor: Use jose instead of node-jose * refactor: Use jose instead of node-jose Reduces the number of dependencies since other libraries also depend on jose. * Update src/identity/configuration/KeyGeneratingIdpConfigurationGenerator.ts Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com> * refactor: Use interfaces instead of abstract classes * refactor: Make WebIdOwnershipValidator an AsyncHandler * refactor: Make TemplateRenderer an AsyncHandler * fix: Fix typing issue * fix: Convert JWK to plain object for node 15 * feat: Update CI configuration --ignore-scripts was removed because it also stopped dependency scripts, which was a requirement for bcrypt. 15.0 was removed since that version doesn't run the required scripts after install. 14.0 was removed since the somehow it caused the solid-authn client to do the wrong calls. * test: Run integration tests on Node 14.2 This is the lowest 14.x version where the IdP integration tests succeed. * feat: Use ErrorResponseWriter for handling oidc errors * test: Mock Date in OidcInteractionCompleter tests * fix: Correctly generate new identifiers Previously there could be double slashes if the base URL ended in slash. * fix: Correctly handle storagePathName in ExpiringStorageAdapterFactory * fix: Fix issue with new CliRunner test in rebase * fix: Handle unknown errors more consistently * feat: Make idp parameter dynamic * feat: Add more logging * refactor: Link css instead of injecting * fix: Fix redis integration tests with idp * refactor: Shorten idp class names * refactor: Remove e-mail configuration from default config * feat: Store JsonResourceStorage data in a single container * feat: Make sure expired data gets removed at some point * feat: Only accept strings as keys in KeyValueStorage * fix: Various minor fixes based on review Co-authored-by: Matthieu Bosquet <matthieubosquet@gmail.com> Co-authored-by: Joachim Van Herwegen <joachimvh@gmail.com>
9.0 KiB
Community Solid Server
An open and modular implementation of the Solid specifications
-
Community Solid Server is open software to provide people with their own Solid Pod.
-
It will give developers an environment to create and test new Solid applications.
-
Its modular architecture allows trying out new ideas on the server side and thereby shape the future of Solid.
Current status
This server is in beta stage, which means you can start using it for developing and testing apps, with some limitations:
- User account / pod creation is not yet supported fully, and you must rely on an external identity provider to log you in and authenticate your WebID. solid/node-solid-server or any other pod provider can serve this purpose, and all you need to do is pass in an external WebID when creating pods. More information on creating pods can be found under Interacting with the server.
- The spec is still under active development, and as such some features (like
trustedApps
) are not yet implemented because they are likely to change. If your users rely on this functionality, migrating is not yet recommended.
Your feedback is most welcome as issues on this repository.
However, you can already boot up the server, play around with it, and check how it is made.
The 📗 API documentation and
the 📐 architectural
diagram
can help you find your way. The organization and structure of the classes and
components in the src folder is designed to align with this
architectural diagram to the extent possible (i.e. the ldp folder
should contain all the components from the ldp
section of the diagram.
If you are interested in helping out with the development of this server, be sure to have a look at the 📓 developer notes and 🛠️ good first issues.
Running the server
Configuring the server
Community Solid Server (CSS) uses
ComponentJS to manage all
configuration for the server. There are a variety of configuration files for
common use cases in the config
folder.
Additional recipes for configuring and deploying the server can be found at solid/community-server-recipes.
Parameter | Default | Description |
---|---|---|
--port, -p |
3000 |
|
--baseUrl. -b |
"http://localhost:$PORT/" |
Needs to be set to the base URL of the server for authnetication and authorization to function. |
--config, -c |
"config/config-default.json" |
config-default.json stores all data in memory. If you would like to persist data to your filesystem, try config-file.json |
--mainModulePath, -m |
Absolute path to the package root from which ComponentJS module resolution should start. | |
--loggingLevel, -l |
"info" |
|
--rootFilePath, -f |
"./" |
Folder to start the server in when using a file-based config. |
--sparqlEndpoint, -s |
Endpoint to call when using a SPARQL-based config. | |
--podConfigJson |
"./pod-config.json" |
JSON file to store pod configuration when using a dynamic config. |
--idpTemplateFolder |
"templates/idp" |
Folder containing the templates used for IDP interactions. |
Installing and running locally
$ npm ci
$ npm start [-- ARGS]
Interacting with the server
CSS is still under active development, and as such the easiest and fastest way to understand what functionality is supported is to read the integration tests. This section is only intended as a high level summary of what's supported.
The server supports low-level interaction via HTTP methods, such as GET
,
PUT
, HEAD
, ...
Below, we provide several examples on how to interact with the server using
curl
.
POST
: Creating a new pod
Create a pod using an external WebID for authentication:
curl -X POST -H "Content-Type: application/json" \
-d '{"login": "timbl", "webId": "http://timbl.inrupt.net/profile/card#me"}' \
http://localhost:3000/pods
PUT
: Creating resources for a given URL
Create a plain text file:
curl -X PUT -H "Content-Type: text/plain" \
-d "abc" \
http://localhost:3000/myfile.txt
Create a turtle file:
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
Create a plain text file:
curl -X POST -H "Content-Type: text/plain" \
-d "abc" \
http://localhost:3000/
Create a turtle file:
curl -X POST -H "Content-Type: text/turtle" \
-d "<ex:s> <ex:p> <ex:o>." \
http://localhost:3000/
The response's Location
header will contain the URL of the created resource.
GET
: Retrieving resources
Retrieve a plain text file:
curl -H "Accept: text/plain" \
http://localhost:3000/myfile.txt
Retrieve a turtle file:
curl -H "Accept: text/turtle" \
http://localhost:3000/myfile.ttl
Retrieve a turtle file in a different serialization:
curl -H "Accept: application/ld+json" \
http://localhost:3000/myfile.ttl
DELETE
: Deleting resources
curl -X DELETE http://localhost:3000/myfile.txt
PATCH
: Modifying resources
Currently, only patches over RDF resources are supported using SPARQL Update
queries without WHERE
clause.
curl -X PATCH -H "Content-Type: application/sparql-update" \
-d "INSERT DATA { <ex:s2> <ex:p2> <ex:o2> }" \
http://localhost:3000/myfile.ttl
HEAD
: Retrieve resources headers
curl -I -H "Accept: text/plain" \
http://localhost:3000/myfile.txt
OPTIONS
: Retrieve resources communication options
curl -X OPTIONS -i http://localhost:3000/myfile.txt
Run using Docker
A Docker image is available to run the containerised Solid Community Server against your filesystem.
Common usage:
- Build the Docker image
docker build --rm -f Dockerfile -t css:latest .
- Run the image against your
~/Solid
directory onhttp://localhost:3000
docker run --rm -v ~/Solid:/data -p 3000:3000 -it css:latest
- Use alternative versions of the built in config. The filestorage is just the default configuration, you can override with any of the configurations included with the server
Or override it with your own config mapped to the right directorydocker run --rm -p 3000:3000 -it css:latest -c config/config-default.json
docker run --rm -v ~/solid-config:/config -p 3000:3000 -it css:latest -c /config/my-config.json
Using the identity provider
-
Launch the Community Solid Server:
git clone git@github.com:solid/community-server.git cd community-server npm ci npm start
-
To use the identity provider, you need a compatible client application.
You can use for example
@inrupt/solid-client-authn-js
:git clone https://github.com/inrupt/solid-client-authn-js cd solid-client-authn-js npm ci cd packages/node/example/demoClientApp/ npm ci npm start
Go to
http://localhost:3001
. -
Use the base URL of your running CSS instance to as Identity provider, for example
http://localhost:3000
, to fill the form. Click thelogin
button. -
Follow the instructions to register/login/...
A WebID hosted in your pod will be required to complete registration.
In your running community server, you could create
http://localhost:3000/profile/card
with the following content:PREFIX : <#> PREFIX solid: <http://www.w3.org/ns/solid/terms#> :me solid:oidcIssuer <http://localhost:3000/> .
When registering, follow the on screen instructions and add the OIDC issuer registration token to your WebID, which you can do for example by PATCHing
http://localhost:3000/profile/card
with:PREFIX : <#> PREFIX solid: <http://www.w3.org/ns/solid/terms#> INSERT DATA { :me solid:oidcIssuerRegistrationToken "IDP_TOKEN" . }
-
Once logged in, you are redirected to your client app, running for example on
http://localhost:3001/
. -
You're now authenticated and can fetch public and private resources.