Skip to content

Update project dependencies#432

Merged
paulapreuss merged 29 commits intomainfrom
fix/security
Mar 19, 2026
Merged

Update project dependencies#432
paulapreuss merged 29 commits intomainfrom
fix/security

Conversation

@paulapreuss
Copy link
Copy Markdown

@paulapreuss paulapreuss commented Jan 15, 2026

OpenPlan is currently based on python 3.9, which has already reached it's EoL, and Django 4.2, which has its long term support (LTS) phase also ending at the end of the year. Additionally, most project dependencies have not been updated in a long time, posing possible security issues, among other things.

This PR aims to upgrade the project to python 3.12 and Django 5.2 (as a compromise between a jump to all latest versions and moving to versions that have at least two years of long term support ahead). Other project dependencies will also be checked for upgrades.

Within this PR, oemof packages are also upgraded to oemof-solph==0.5.7 and oemof-thermal==0.0.8. Will have to do some testing. Likely these versions were pinned to be in sync with MVS, but since we are moving away from MVS we will need to update anyway. The upgrade was necessary, since the package dependencies were not compatible with python 3.12.

Closes #399

TODO:

  • Check and potentially update security settings
  • Update README
  • Update local deploy settings / instructions
  • Include build test
  • Set up dependabot

@paulapreuss paulapreuss force-pushed the fix/security branch 2 times, most recently from 1a0275b to f412f35 Compare January 15, 2026 15:05
Copy link
Copy Markdown

@Bachibouzouk Bachibouzouk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just though yesterday that we were due to update django. Shouldn't we unpin the dependencies ? I would keep a file with pinned dependencies but use the one with unpinned such that we always get the latest updates when we deploy (we could setup a scheduled job to build using the unpinned requirements and be notifyed when it fails). If it fails and it is a friday or one day before a workshop and one has no time, we can fallback on the pinned dependencies and leave it as TODO to fix the dependencies later.

Depends on new environment variable `PROD_ENV` being set to true
@paulapreuss paulapreuss force-pushed the fix/security branch 2 times, most recently from 4136233 to b772c7c Compare March 9, 2026 09:43
@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 9, 2026

✅dependabot config looks good 👍

@paulapreuss
Copy link
Copy Markdown
Author

paulapreuss commented Mar 9, 2026

Hi @Bachibouzouk, I think this is about ready. What I did:

  • Upgrade Django to 5.2
  • Upgrade python to 3.12
  • Upgrade all other packages, only pinning the ones triggering version conflicts or causing other issues in the code
  • Differentiate between docker-compose-production and docker-compose-local and update local deployment description
  • Add build test on CI (builds local-compose-local to check that the requirements are working and there are no migration files are missing)
  • Add a basic dependabot configuration (we will have to see if this is catching all we are interested in, it is hard to test locally)
  • Add a github action to automatically tag releases when they get merged into prod
  • Update the pre-commit config to be quite a bit stricter (now uses ruff and a few other hooks) - this has also caused the changed files to be so huge, since I ran it once on the repo. It should mostly be code formatting, though. Locally, you should update your pre-commit config with pre-commit install.

Let me know what you think. I did change quite a few things so I assume this will take quite a bit of noodling around on staging to make sure that everything really still works as intended.

One thing I have not yet done is move from Django-q to celery beat. I will do this when I have a bit of time again.

Also, I have now included the changes from your other closed PRs to the Changelog here, as they were still missing.

@paulapreuss paulapreuss marked this pull request as ready for review March 9, 2026 14:40
# https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-secure
CSRF_COOKIE_SECURE = True
# https://docs.djangoproject.com/en/dev/ref/settings/#secure-hsts-seconds
# TODO: set this to 60 seconds first and then to 518400 once you prove the former works
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NB: make sure this is addressed in a later commit

# https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-secure
CSRF_COOKIE_SECURE = True
# https://docs.djangoproject.com/en/dev/ref/settings/#secure-hsts-seconds
# TODO: set this to 60 seconds first and then to 518400 once you prove the former works
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we set it to 518400 ?

Copy link
Copy Markdown
Author

@paulapreuss paulapreuss Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Bachibouzouk I would keep it as is for now and then gradually increase before moving from staging to production? We can also set it a bit higher already, but I wouldn't go to 518400 right away.

Copy link
Copy Markdown

@Bachibouzouk Bachibouzouk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so far I got for the moment, testing the production on the sandbox server

from django.templatetags.static import static
from numbers import Number

from epa.settings import RESOURCES_DIR
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you test if the path is accessible in production?

"orm": "default",
}

if PROD_ENV:
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I set prod env to False I get the sandbox to work, if not I makes and endless ssl redirect and ends up with a ns-error-redirect-loop error

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown

@Bachibouzouk Bachibouzouk Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When one sets PROD_ENV to True while setting DJANGO_SECURE_SSL_REDIRECT to False, then it works :)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Bachibouzouk I added SECURE_PROXY_SSL_HEADER to the settings as recommended by the documentation, now the DJANGO_SECURE_SSL_REDIRECT setting also seems to work without endless redirects.

Bachibouzouk and others added 2 commits March 13, 2026 00:20
Should fix SECURE_SSL_REDIRECT causing infinite loops
@paulapreuss
Copy link
Copy Markdown
Author

paulapreuss commented Mar 18, 2026

@Bachibouzouk I also toyed around a bit on the sandbox server with this and it looks to be working. Are you good with merging it into main/staging?

@paulapreuss paulapreuss merged commit 2222a53 into main Mar 19, 2026
2 checks passed
@paulapreuss paulapreuss deleted the fix/security branch March 19, 2026 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Update dependencies

2 participants