Creating engagement without name through the API results in 500 on Active Engagement page

[ericcornelissen]

Bug description

It is possible to create an engagement through the API successfully that causes problems in other parts of the server, e.g. when visiting the "Active Engagements" page which produces the following error ⬇️ I did collect an exhaustive list of which pages/API endpoints show this behaviour after creating the faulty engagement.

[...]
uwsgi_1 | ERROR:django.request:Internal Server Error: /engagement
uwsgi_1 | Traceback (most recent call last):
uwsgi_1 | File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner
uwsgi_1 | response = get_response(request)
uwsgi_1 | File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 115, in _get_response
uwsgi_1 | response = self.process_exception_by_middleware(e, request)
uwsgi_1 | File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response
uwsgi_1 | response = wrapped_callback(request, *callback_args, **callback_kwargs)
uwsgi_1 | File "./dojo/engagement/views.py", line 123, in engagement
uwsgi_1 | engagement_name_words = sorted(engagements.values_list('name', flat=True).distinct())
uwsgi_1 | TypeError: '<' not supported between instances of 'str' and 'NoneType'
nginx_1 | 172.19.0.1 - eric [10/Jun/2021:09:19:26 +0000] "GET /engagement HTTP/1.1" 500 27 "http://localhost:8080/api/key-v2" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0" "-"
uwsgi_1 | [pid: 19|app: 0|req: 8/15] 172.19.0.1 () {48 vars in 921 bytes} [Thu Jun 10 09:19:26 2021] GET /engagement => generated 27 bytes in 89 msecs (HTTP/1.1 500) 6 headers in 192 bytes (1 switches on core 1)

Steps to reproduce

1. Set these environment variables to the appropriate values or copy them into the samples below.

   export DD_BASE_URL=localhost:8080
   export DD_API_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   export DD_PRODUCT_ID=1
   

2. Create a new engagement with only the required values using the API

   curl -X POST $DD_BASE_URL'/api/v2/engagements/' \
     -H 'Authorization: Token '$DD_API_TOKEN \
     -H 'accept: application/json' \
     -H 'Content-Type: application/json' \
     -d '{"target_start":"2021-06-10","target_end":"2021-06-10","product":'$DD_PRODUCT_ID'}'
   

3. Observe that the request is successfull. Take note of the id of the created engagement.

4. Check the "Active engagements" page and see "Server Error (500)"

Cleanup:

5. Set an environment variable for the id of the engagement we just created, or copy it into the sample below.

   export DD_ENGAGEMENT_ID=25
   

6. Fix your DefectDojo instance using this command.

   curl -X DELETE $DD_BASE_URL'/api/v2/engagements/'$DD_ENGAGEMENT_ID'/' \
     -H 'Authorization: Token '$DD_API_TOKEN \
     -H 'accept: application/json'
   

Expected behavior
Visiting the "Active Engagement" page should not give an error after creating an engagement successfully. Either the server should handle whatever engagement was created without producing an error OR the API should not create engagement that miss required parameters.

Deployment method (select with an X)

• Kubernetes
• Docker
• setup.bash / legacy-setup.bash

Environment information

• Operating System: Mac 11.4
• DefectDojo Commit Message: [2021-05-16 20:16:50 +0200] 2d6067f6: Update CONTRIBUTING.md [ (HEAD -> master, origin/master, origin/HEAD)]

Sample scan files (optional)
n/a

Screenshots (optional)
n/a

Console logs (optional)
n/a

Additional context (optional)
Based on my research it seems that the "name" input for engagement is required, contrary to what the schema definition defines. When creating an engagement in the UI this doesn't seem to be a problem as the start date is automatically used for the engagement name if no name was explicitly provided.

This issue seems related to #3121 and #3342

[valentijnscholten]

fixed in dev / 2.0.0