From feb37dbd8091d989e38cbdce9e5b81fc87316c20 Mon Sep 17 00:00:00 2001 From: Kayode Ezike Date: Wed, 24 Apr 2024 04:46:31 -0400 Subject: [PATCH] additional cleanup --- README.md | 33 +++++++++++++++++++++------------ src/app.js | 7 ++++++- 2 files changed, 27 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 5533f2e..e9dcba4 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ IMPORTANT NOTE ABOUT VERSIONING: If you are using a Docker Hub image of this rep ## Summary -A microservice (running as a nodejs express app) that uses a database service to allocate a [status position](https://www.w3.org/TR/vc-bitstring-status-list) for a [Verifiable Credential](https://www.w3.org/TR/vc-data-model), adds the position to the credential, and returns the credential. The status position can later be used to revoke the credential. +A microservice (running as a nodejs express app) that uses a database service to allocate a [status position](https://www.w3.org/TR/vc-bitstring-status-list) for a [Verifiable Credential](https://www.w3.org/TR/vc-data-model-2.0), adds the position to the credential, and returns the credential. The status position can later be used to revoke the credential. Implements two HTTP endpoints: @@ -97,7 +97,7 @@ This express app can be run a few different ways: You can now allocate status positions for Verifiable Credentials. Try it out with this cURL command, which you simply paste into the terminal: -``` +```bash curl --location 'http://localhost:4008/credentials/status/allocate' \ --header 'Content-Type: application/json' \ --data-raw '{ @@ -149,7 +149,7 @@ curl --location 'http://localhost:4008/credentials/status/allocate' \ This should return the same credential but with an allocated status. It should look something like this (it will be all smushed up, but you can format it in something like [JSONLint](https://jsonlint.com)): -``` +```json { "@context": [ "https://www.w3.org/ns/credentials/v2", @@ -222,8 +222,11 @@ NOTE: cURL can get a bit clunky if you want to experiment more (e.g., by changin Revocation and suspension are fully explained in the [Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/) specification and our implemenations thereof, but effectively, it amounts to POSTing an object to the revocation endpoint, like so: -``` -{credentialId: '23kdr', credentialStatus: [{type: 'BitstringStatusListCredential', status: 'revoked'}]} +```json +{ + "credentialId": "urn:uuid:951b475e-b795-43bc-ba8f-a2d01efd2eb1", + "credentialStatus": [{ "type": "BitstringStatusListCredential", "status": "revoked" }] +} ``` Fundamentally, you are just posting up the ID of the credential. @@ -262,17 +265,21 @@ Logging is configured with environment variables, as defined in the [Environment By default, everything is logged to the console (log level `silly`). -You may set the log level for the application as whole, e.g., +You may set the log level for the application as a whole. For example: -```LOG_LEVEL=http``` +``` +LOG_LEVEL=http +``` Which would only log messages with severity `http` and all below it (`info`, `warn`, `error`). The default is to log everything (level `silly`). -You can also set the log level for console logging, e.g., +You can also set the log level for console logging. For example: -```CONSOLE_LOG_LEVEL=debug``` +``` +CONSOLE_LOG_LEVEL=debug +``` This would log everything for severity `debug` and lower (i.e., `verbose`, `http`, `info`, `warn`, `error`). This of course assumes that you've set the log level for the application as a whole to at least the same level. @@ -283,7 +290,7 @@ There are also two log files that can be enabled: - errors (only logs errors) - all (logs everything - all log levels) -Enable each log by setting an env variable for each, indicating the path to the appropriate file, like this example: +Enable each log by setting an environment variable for each, indicating the path to the appropriate file, like this example: ``` ERROR_LOG_FILE=logs/error.log @@ -308,7 +315,7 @@ To enable access logging, set `ENABLE_ACCESS_LOGGING` to `true`. Clone code then cd into directory and: -``` +```bash npm install npm run dev ``` @@ -317,7 +324,9 @@ npm run dev Testing uses `mocha` and `supertest` to test the endpoints. To run tests: -```npm run test``` +```bash +npm run test +``` Because `status-service-db` uses database services to manage status, calls are made out to HTTP API endpoints during issuance. Rather than making these calls for every test, and possibly in cases where outgoing HTTP calls aren't ideal, we've mocked the `@digitalcredentials/credential-status-manager-db` package. diff --git a/src/app.js b/src/app.js index 5ab94c4..72b636d 100644 --- a/src/app.js +++ b/src/app.js @@ -47,7 +47,12 @@ export async function build(opts = {}) { // Update status // The body will look like: - // {credentialId: '23kdr', credentialStatus: [{type: 'BitstringStatusListCredential', status: 'revoked'}]} + /* + { + "credentialId": "urn:uuid:951b475e-b795-43bc-ba8f-a2d01efd2eb1", + "credentialStatus": [{ "type": "BitstringStatusListCredential", "status": "revoked" }] + } + */ app.post('/credentials/status', async function (req, res, next) { try {