Work with a base Restspace setup
The Restspace base setup has functionality to manage authentication and users, plus ability to read and write JSON data. It also has a service to manage the admin ui. If you click on the Site Header (at the top of the navigation) you'll see the services.json for the site, it looks like this:
{
"services": [
{
"name": "adminSite",
"serviceName": "staticSite",
"adapterName": "localFileSystemAdapter",
"adapterConfig": {
"filePathRoot": "/admin"
},
"basePath": "/admin",
"readRoles": "all",
"writeRoles": "A",
"defaultResource": "index.html",
"divertMissingToDefault": true
},
{
"name": "authentication",
"serviceName": "authentication",
"basePath": "/auth",
"readRoles": "all",
"writeRoles": "all",
"userUrlPattern": "/json/user/${email}"
},
{
"name": "users",
"serviceName": "userService",
"adapterName": "localFileDataAdapter",
"adapterConfig": {
"filePathRoot": "/json/user"
},
"basePath": "/json/user",
"readRoles": "{email} E",
"writeRoles": "{email} E",
"createRoles": "all"
},
{
"name": "json",
"serviceName": "jsonService",
"adapterName": "localFileDataAdapter",
"adapterConfig": {
"filePathRoot": "/json"
},
"basePath": "/json",
"readRoles": "all",
"writeRoles": "E A"
}
],
"domainsServing": [
"base.restspace.io"
]
}
Explanation of the services is as below:
- This
staticSite
service hosts the React SPA which implements the Restspace admin interface. The base path/admin
is where you go to access this interface. The adapter islocalFileSystemAdapter
, as the React files are stored on the file system local to the server. You could for instance change this tos3FileAdapter
(still to be developed) to have the files stored in AWS S3 (which might be needed to enable the Restspace server to run as a severless function). ThereadRoles
are 'all' so that anyone can download the admin interface - this is necessary so you can log in initially. ThewriteRoles
are 'A' as only the Admin should be able to make changes to this setup.defaultResource
says that going to the/admin
path should load theindex.html
file.divertMissingToDefault
tells the server to serve theindex.html
file also for any path under/admin
where there is no other static file. - The
authentication
service manages login and getting user details. The authentication endpoints live under/auth
. Anyone must be able to log in soreadRoles
(andwriteRoles
) are 'all'. TheuserUrlPattern
tells the system where to find the user data for a login. This uses a url pattern (see the documentation) which appends the email property of the data posted to the/login
endpoint to/json/user
to get the url of the logging in user's record. - The
userService
service manages accessing user records so that passwords are hashed and obfuscated on reading, and to ensure a user has the right permissions for any change made to the user record. Since this is listed before thejsonService
, it intercepts requests it would normally handle, and it is an overlay on its path space, adding filters to the access to the/json/user
subpath. ThereadRoles
andwriteRoles
include the{email}
user path matching component. This means for a user to have access to the user record, their email property must be one of the path segments on the url of the record. Anyone can create a user: this is registration.
An editor can access the schema for users as for anyjsonService
by clicking on the Users service heading. You can add any properties to a user record you like by adding property definitions to the schema. - The
jsonService
service handles storing JSON on urls. ThelocalFileSystemAdapter
stores this data on the local filesystem. Anonymous read access is the default (theuserService
above overrides this for resources on the/json/user
subpath). An Editor or Admin can edit the data.jsonService
needs a JSON schema configured for any directory to which you add a JSON file. These are accessed by clicking the folder or service header. The documentation forjsonService
also describes how to do OData style queries to fetch sets of JSON files.