prechelt / anwesende Goto Github PK

The base template includes assets from third-party CDNs:

<link href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
…
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.3/umd/popper.min.js" integrity="sha384-ZMP7rVo3mIykV+2+9J3UJ46jBk0WLaUAdn689aCwoqbBJiSnjAK/l8WvCWPIPm49" crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>

Since you don't pay for server's web traffic, there is really no good reason not to serve the assets yourself.

Then you could also add a content-security-policy that prevents any cross-origin connections to make the app a little safer.

Dear Prof. Dr. Prechelt @prechelt

Commit 9bbe56a which is openly found in this repository contains username and password for the PostgreSQL database (I use [HIDDEN] in this issue to prevent the information from leaking through this issue):

POSTGRES_DB=anwesende
POSTGRES_USER=[HIDDEN]
POSTGRES_PASSWORD=[HIDDEN]

Furthermore, the same commit also leaks the DJANGO_SECRET_KEY for the local (config/settings/local.py), test (config/settings/test.py), and production (config/settings/production.py) servers:

SECRET_KEY = env(
    "DJANGO_SECRET_KEY",
    default="[HIDDEN]",
)

I hope this username, password, and DJANGO_SECRET_KEY information is out of date, but even so you might want to remove this commit, and associated files / information from the repository history (and of course change the password/secret keys when they are the real ones).

Kind regards,
Dr. Danny Arends

I wanted to set up this software w/o Docker (and using our pre-existing postgres clustre) since I don't know how to use docker and less complexity means less potential for bugs or setup frustration.

This was mostly a non-issue but it required a modified start-file and a patch to config/settings/production.py which I'll attach for others wanting to do the same.

The general steps were as follows:

1. create a local user (anwesende with home directory /var/lib/anwesende in my case) and clone the repo
2. Run anw.sh - prepare_env.
3. Modify the env files as normal, but add USE_DOCKER=no to myenv.env
4. Run anw.sh production install. It will error due to missing docker_compose but it creates the .envs/autogenerated.env file which we'll need.
5. Install the python dependencies into a virtualenv, e.g. using pipenv: $ pipenv install -r requirements.txt
6. Apply the config patch: $ git apply config.patch
7. Start the server with $ DJANGO_READ_DOT_ENV_FILE=True pipenv run ./start.sh or with the service file attached below.

start.sh:

#!/bin/bash

set -o errexit
set -o pipefail
set -o nounset

# import the env
set -o allexport
source .envs/autogenerated.env
source .envs/production.sh
set +o allexport

python manage.py collectstatic --noinput
python manage.py migrate
python manage.py make_base_data

gunicorn config.wsgi \
    --worker-class gthread \
    --workers 5 \
    --threads 4 \
    --max-requests 4000 \
    --max-requests-jitter 111 \
    --bind localhost:5000

config.patch

diff --git a/config/settings/production.py b/config/settings/production.py
index 736c42e..ef7bbcf 100644
--- a/config/settings/production.py
+++ b/config/settings/production.py
@@ -10,7 +10,7 @@ ALLOWED_HOSTS = env.list("DJANGO_ALLOWED_HOSTS")

 # DATABASES
 # ------------------------------------------------------------------------------
-DATABASES["default"] = env.db("DATABASE_URL")  # noqa F405
+#DATABASES["default"] = env.db("DATABASE_URL")  # noqa F405
 DATABASES["default"]["ATOMIC_REQUESTS"] = True  # noqa F405
 DATABASES["default"]["CONN_MAX_AGE"] = env.int("CONN_MAX_AGE", default=60)  # noqa F405

@@ -103,19 +103,19 @@ LOGGING = {
         "file": {
             "level": "DEBUG",
             "class": "logging.FileHandler",
-            "filename": '/djangolog/django.log',
+            "filename": '/var/lib/anwesende/anwesende/django.log',
             "formatter": "verbose",
         },
         "file_error": {
             "level": "ERROR",
             "class": "logging.FileHandler",
-            "filename": '/djangolog/django-errors.log',
+            "filename": '/var/lib/anwesende/anwesende/django-errors.log',
             "formatter": "verbose",
         },
         "file_search": {
             "level": "INFO",
             "class": "logging.FileHandler",
-            "filename": '/djangolog/django-requests.log',
+            "filename": '/var/lib/anwesende/anwesende/django-requests.log',
             "formatter": "verbose",
         },
     },

anwesende.service

[Unit]
Description=Run 'anwesende' service

[Service]
Type=simple
User=anwesende
Environment=DJANGO_READ_DOT_ENV_FILE=True
ExecStart=/usr/bin/pipenv run ./start.sh
WorkingDirectory=/var/lib/anwesende/anwesende

[Install]
WantedBy=multi-user.target

@prechelt if it isn't too much hassle maybe you could make the config.patch unnecessary in future releases? I don't really know Django enough to understand why that particular call to env.db errors with a key error, but it does. The application writes and reads to the (remote) postgres completely fine though.

The example page for QRCodes causes the body element to overflow on mobile screens.

Suggestions:
Assuming the ui library is bootstrap the qrcode area could be wrapped in responsive grid classes

Docs:
https://getbootstrap.com/docs/5.0/layout/grid/#stacked-to-horizontal

I could also create a PR to fix this.
Are there any contribution guidelines?

Attached video demonstrating the issue:

https://box.fu-berlin.de/s/ABtJQbMdyjWRFa4

Geräte und Browser die zuerst die Verbindung auf https upgraden bevor sie dem Location header folgen, bekommen eine Warnung, dass ein selbstsigniertes Zertifikat für eine falsche domain verwendet wird. Wenn eine Ausnahme hinzugefügt wird, werden sie trotzdem nicht auf https://anwesende.imp.fu-berlin.de/ weitergeleitet, sondern bekommen 404 page not found ausgeliefert.

To make it easier to verify which seats are already checked in and which are not it might be helpful to have a schematic view of the available seats in the rooms (e.g. a table) and mark the ones which are checked in, maybe even give a number of different people checked in for the same seat (if the systems provides it). Something like the following table where I marked checked-in seats with an asterisk.

+-----+-----+-----+-----+
|r1s1 |r1s2 |r1s3*|r1s4 |
+-----+-----+-----+-----+
|r2s1 |r2s2*|r2s3 |r2s4 |
+-----+-----+-----+-----+
|r3s1 |r3s2 |r3s3*|r3s4 |
+-----+-----+-----+-----+

I know that this view might not resemble the actual room situation if many qr codes are not placed. But it might actually be possible to shape the table cells in width and height such that they represent the room's row_dist and seat_dist.

I might try to implement this feature myself but I don't know whether that'll happen in the near future. I'll leave it as a suggestion here until then.

As mentioned in the README under point 4.7, the command does not work:
./anw.sh production.sh onserver docker-compose run --rm django python manage.py createsuperuser --username superuser

Follow command worked for me:
./anw.sh production docker-compose run --rm django python manage.py createsuperuser --username superuser

May you can update the README