mlinke-ai commented 1 year ago

The structure of the back end had some issues with running as a standalone application and executing the tests, so I wrote it completely new from scratch. This introduces the following features and changes.

Features

[X] the server has an extensive configuration system
[X] all database interactions use the ORM model
[X] pagination works on all GET requests
[X] authentication is handled by flask_jwt_extended
[X] token refreshing is handled by callback function
[X] tests use flask_unittest and don't rely on actual requests to localhost anymore
[X] the server runs in a production ready environment using uWSGI
[ ] the server can be deployed as a Docker container

Changes

Because of the new authentication handling there is one breaking change:

There are now two cookies in the header: the access_token_cookie which contains the necessary information about the user and a second cookie called csrf_access_token. This token prevents cross site scripting attacks. Handling of this token is fairly simple: before every request, one has to write the value of the csrf_access_token into a header field called X-CSRF-TOKEN. Otherwise authentication will fail.

Another small change is that the /logout route now provides the DELETE method and not the POST method any more (this seems to be the standard).

Looby72 commented 1 year ago

Okay, I think I need a littlebit to understand your changes.

How am I supposed to run the flask application now? Executing run.py now does not work anymore for me.

Do we have todo further changes to e.g. the documentation or other files to have everything consistent, or did you consider all this already?

I hope we dont dicorver any big issues, since we have to submit our code tomorrow.

Looby72 commented 1 year ago

@Pymon has to change the logout routine in the frontend, as the Logout HTTP-method changed to DELETE. Otherwise logging out might not work.

mlinke-ai commented 1 year ago

The server runs now with uWSGI. The command is uwsgi --ini uwsgi.ini. The config file should should handle everything. On Windows you might have to use pip to install uWSGI. On UNIX systems you can use the package manager (the two packages are called uwsgi and uwsgi-plugin-python3 on Fedora).

I didn't make any logical changes so most parts should behave like before. Therefore the documentation should still be valid.

I am also somewhat worried about the submission as we still have over a dozen feature branches.

Looby72 commented 1 year ago

I think most of our open feature branches can easily be deleted as nobody is working on that anymore. I think everyone has completed the work on their branches by now. Or don't want to add any new features until tomorrow.

Looby72 commented 1 year ago

On my windows system I get an error when I try to use:

pip install uWSGI

Collecting uWSGI
  Using cached uwsgi-2.0.21.tar.gz (808 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [8 lines of output]
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "\setup.py", line 3, in <module>
          import uwsgiconfig as uc
        File "\uwsgiconfig.py", line 8, in <module>
          uwsgi_os = os.uname()[0]
      AttributeError: module 'os' has no attribute 'uname'. Did you mean: 'name'?
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

mlinke-ai commented 1 year ago

The changes in the front end are made by my pre-commit hooks (unified line endings, trailing newline, etc.). Those changes will not be part of the PR. I will overwrite them with the existing files from the develop branch.

In my opinion your work would be to write a helper function which reads the content of the one cookie and writes it into the header of the request. Maybe there is a way to register this helper function as a hook to all the requests. If this is not possible the tedious way would be to change every function which makes a request by hand. But Ctrl+F should speed up this process. However I don't want to pressure you to waste your evening because of me.

Regarding your concerns about the git history, your thoughts are quite valid but I don't have any solution to circumvent this. Technically I am not erasing all previous commits, they are still there. I am just adding new ones which is a natural process of software development.

I will not have time to work on the project tomorrow or on the weekend. So my proposal would be to finalize the current develop branch and the other feature branches into something like a v0.1.0 release which is somewhat working and which we can submit tomorrow. And in the future (rather sooner than later) we complete this pull request.

mlinke-ai commented 1 year ago

On my windows system I get an error when I try to use:

pip install uWSGI

Collecting uWSGI
  Using cached uwsgi-2.0.21.tar.gz (808 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [8 lines of output]
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "\setup.py", line 3, in <module>
          import uwsgiconfig as uc
        File "\uwsgiconfig.py", line 8, in <module>
          uwsgi_os = os.uname()[0]
      AttributeError: module 'os' has no attribute 'uname'. Did you mean: 'name'?
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

I just found out uWSGI does not work on Windows.

Looby72 commented 1 year ago

The changes in the front end are made by my pre-commit hooks (unified line endings, trailing newline, etc.). Those changes will not be part of the PR. I will overwrite them with the existing files from the develop branch.

In my opinion your work would be to write a helper function which reads the content of the one cookie and writes it into the header of the request. Maybe there is a way to register this helper function as a hook to all the requests. If this is not possible the tedious way would be to change every function which makes a request by hand. But Ctrl+F should speed up this process. However I don't want to pressure you to waste your evening because of me.

Regarding your concerns about the git history, your thoughts are quite valid but I don't have any solution to circumvent this.

I will not have time to work on the project tomorrow or on the weekend. So my proposal would be to finalize the current develop branch and the other feature branches into something like a v0.1.0 release which is somewhat working and which we can submit tomorrow. And in the future (rather sooner than later) we complete this pull request.

I would agree with that. There is a high risk of deploying a very chaotic and maybe not fully working system if we have to submit our work tomorrow.

mlinke-ai / kev_in

Rework of the whole backend #217

Features

Changes