DefectDojo 404 /login

[marciogchahad]

Hello guys!
I have an access issue in DefectDojo. When I'm trying to access the login screen, I'm getting a 404 message.
I'm running DefectDojo on a cluster of Kubernetes and the services are isolated by pods (nginx, uwsgi, celerybeat, celeryworker, rabbitmq).

Access Flow:
mydomain.com ===> ELB (80/443) ==={redirect to nginx service on 8080 using SSL Offloading} ===> EKS Service (nginx 8080) ===> django

Below is the message:

Pod logs:
WARNING:django.request:Not Found: /login

Debug Django Message:
Using the URLconf defined in dojo.urls, Django tried these URL patterns, in this order: ^mydomain.comapi/v2/ ^mydomain.comhistory/(?P<cid>\d+)/(?P<oid>\d+)$ [name='action_history'] ^mydomain.com ^mydomain.comapi/v2/api-token-auth/ ^mydomain.comapi/v2/doc/ [name='api_v2_schema'] ^mydomain.comapi/v2/oa3/schema/ [name='schema_oa3'] ^mydomain.comapi/v2/oa3/swagger-ui/ [name='swagger-ui_oa3'] ^robots.txt [name='robots_file'] ^manage_files/(?P<oid>\d+)/(?P<obj_type>\w+)$ [name='manage_files'] ^questionnaire$ [name='questionnaire'] ^questionnaire/create$ [name='create_questionnaire'] ^questionnaire/(?P<sid>\d+)/edit$ [name='edit_questionnaire'] ^questionnaire/(?P<sid>\d+)/delete [name='delete_questionnaire'] ^questionnaire/(?P<sid>\d+)/edit/questions$ [name='edit_questionnaire_questions'] ^questions$ [name='questions'] ^questions/add$ [name='create_question'] ^questions/(?P<qid>\d+)/edit$ [name='edit_question'] ^choices/add$ [name='add_choices'] ^engagement/(?P<eid>\d+)/add_questionnaire$ [name='add_questionnaire'] ^engagement/(?P<eid>\d+)/questionnaire/(?P<sid>\d+)/answer [name='answer_questionnaire'] ^engagement/(?P<eid>\d+)/questionnaire/(?P<sid>\d+)/delete [name='delete_engagement_survey'] ^engagement/(?P<eid>\d+)/questionnaire/(?P<sid>\d+)$ [name='view_questionnaire'] ^engagement/(?P<eid>\d+)/questionnaire/(?P<sid>\d+)/assign [name='assign_questionnaire'] ^empty_questionnaire$ [name='add_empty_questionnaire'] ^empty_questionnaire/(?P<esid>\d+)$ [name='view_empty_survey'] ^empty_questionnaire/(?P<esid>\d+)/delete$ [name='delete_empty_questionnaire'] ^general_questionnaire/(?P<esid>\d+)/delete$ [name='delete_general_questionnaire'] ^empty_questionnaire/(?P<esid>\d+)/answer$ [name='answer_empty_survey'] ^empty_questionnaire/(?P<esid>\d+)/new_engagement$ [name='engagement_empty_survey'] ^mydomain.comadmin/ ^media/(?P<path>.*)$ =====> The current path, login, didn't match any of these. <=====

Using the same Docker image, running DefectDojo with docker-compose on my computer, the login page opens correctly.

Does anyone have any idea what it might be?

[marciogchahad]

Hello guys!
I solved the problem. The error occurred due to the Jira plugin, which ended up generating errors in the database. After removing Jira entries from the database the access worked.

[valentijnscholten]

which JIRA plugin are you referring to?

[lcsmontiel]

@chahadze Can u tell us what entries did u deleted on database? I'm experiencing the same problem

[marciogchahad]

Hi guys!!
The problem is the Jira plugin. After set the configuration on the Defectdojo the database received a lot of information from Jira, and the most was error information on the table. After disable this functionality on Defectdojo and clean the table in the database related to Jira, the issue was solved.
I was using version 2.1.0 of Defectdojo. Maybe now this issue was resolved in the new version.

[valentijnscholten]

Can you provide an example of the data that you deleted? Which table are you referring to?

[lcsmontiel]

@valentijnscholten I've been collecting and debugging that problem since yesterday. One of my teammates have enabled Slack and e-mail notifications and after that the dojo_system_settings have been totally 'infected'. U will have a lot of entries using SITE_URL env causing a lot of problems to the routing system. Aparenttly the bug is with the url_preffix field, when that field has information like 'https://FOO-BAR' the routing system require all requests to have that prefix, causing a lot of problems in LIVENESS and READINESS requests

We've fixed that deployng a fresh database then copyng fresh dojo_system_settings to the older database