fix: minor doc and api improvements (#212)

docs/_sidebar.md

@@ -7,7 +7,7 @@
 ** [Generate Account Token](/dev_account_token.md)
 ** [Intention Lifecycle](/dev_intention_lifecycle.md)
 ** [Using Intentions to Access Vault](/dev_intention_usage.md)
-** [Intetion Action Reference](/dev_intention_actions.md)
+** [Intention Action Reference](/dev_intention_actions.md)
 ** [GitHub Actions](/github_actions.md)
 
 * Operations

docs/audit.md

@@ -45,12 +45,12 @@ All auth fields are custom to the Broker audit log.
 
 | Field | Mandatory | Type | Description | Values |
 | ----- | --------- | ---- | ----------- | ------ |
-| auth.client_token | (grey lightbulb) | keyword | Vault client_token (wrapped) that is being provided to an application. Used for tracking usage in Vault audit Index. | See below. Hashed token |
-| auth.exp | (grey lightbulb) | long | JWT Claim | See: Broker JWT |
-| auth.iat | (grey lightbulb) | long | JWT Claim | See: Broker JWT |
-| auth.nbf | (grey lightbulb) | long | JWT Claim | See: Broker JWT |
-| auth.jti | (grey lightbulb) | keyword | JWT Claim | See: Broker JWT |
-| auth.sub | (grey lightbulb) | keyword | JWT Claim | See: Broker JWT |
+| auth.client_token | No | keyword | Vault client_token (wrapped) that is being provided to an application. Used for tracking usage in Vault audit Index. | See below. Hashed token |
+| auth.exp | No| long | JWT Claim | See: [Broker JWT](operations_jwt.md) |
+| auth.iat | No | long | JWT Claim | See: [Broker JWT](operations_jwt.md) |
+| auth.nbf | No | long | JWT Claim | See: [Broker JWT](operations_jwt.md) |
+| auth.jti | No | keyword | JWT Claim | See: [Broker JWT](operations_jwt.md) |
+| auth.sub | No | keyword | JWT Claim | See: [Broker JWT](operations_jwt.md) |
 
 ### Tracking Broker Created tokens in Vault Audit
 

docs/dev_intention_actions.md

@@ -14,7 +14,7 @@
 | process-end | Indicates the ending of a process (shutting down of a service) |
 | process-start | Indicates the starting of a process (starting up of a service) |
 
-The actions are loosely based on Elastic Common Schema event.action which is "more specific than" event.category. The accepted values for event.category are a good starting point if you need to add a new value.
+The actions are loosely based on Elastic Common Schema [event.action](https://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-action) which is "more specific than" [event.category](https://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-category). The [accepted values for event.category](https://www.elastic.co/guide/en/ecs/current/ecs-allowed-values-event-category.html) are a good starting point if you need to add a new value.
 
 The first pass at defining actions directly used the event category and type fields. This proved difficult as the audit logs themselves are events (that should be categorized). The Elastic Common Schema definition for those fields, while logical, had to be twisted to define many actions, obscured what the action was and setting two or more fields was error prone. So, the action became a single separate field, but, we still want it to be similar to the event.action field.
 

src/graph/graph.controller.ts

@@ -214,6 +214,10 @@ export class GraphController {
   @Post('vertex/search')
   @UseGuards(BrokerCombinedAuthGuard)
   @ApiBearerAuth()
+  @ApiQuery({
+    name: 'collection',
+    required: true,
+  })
   @ApiQuery({
     name: 'edgeName',
     required: false,

src/graph/graph.service.ts

@@ -566,6 +566,13 @@ export class GraphService {
     edgeName?: string,
     edgeTarget?: string,
   ) {
+    if (CollectionNameEnum[collection] === undefined) {
+      throw new BadRequestException({
+        statusCode: 400,
+        message: 'Bad request',
+        error: '',
+      });
+    }
     if ((edgeName === undefined) !== (edgeTarget === undefined)) {
       throw new BadRequestException({
         statusCode: 400,