mhu/shimatta-kenkyusho
2
0
Fork 0
Code Issues 13 Pull Requests Releases Wiki Activity

added CSRF trusted origin config, added tzdata - needed in debug mode #22

Merged
mhu merged 2 commits from sst/some-weird-stuff-with-docker into develop 2024-11-21 00:50:08 +01:00
Conversation 4 Commits 2 Files Changed 2 +4 -1
sst commented 2024-11-19 23:10:10 +01:00
Collaborator
Copy Link
No description provided.
sst added 1 commit 2024-11-19 23:10:10 +01:00
mhu requested changes 2024-11-19 23:17:51 +01:00
Dismissed
shimatta_kenkyusho/shimatta_kenkyusho/settings_production.py Outdated
@ -56,6 +56,7 @@ if get_env_value('DJANGO_FORCE_DEV_MODE', default=False) == 'True':
ALLOWED_HOSTS = ['127.0.0.1', 'localhost', get_env_value('DJANGO_ALLOWED_HOST')]
CSRF_TRUSTED_ORIGINS =['https://' + get_env_value('DJANGO_ALLOWED_HOST')]
mhu commented 2024-11-19 23:17:47 +01:00
Owner
Copy Link

This seems very unsafe!

This seems very unsafe!
mhu marked this conversation as resolved
sst added 1 commit 2024-11-19 23:35:18 +01:00
mhu commented 2024-11-19 23:52:55 +01:00
Owner
Copy Link
Warning

Modifying this setting can compromise your site’s security. Ensure you fully understand your setup before changing it.

Make sure ALL of the following are true before setting this (assuming the values from the example above):

1. Your Django app is behind a proxy.
2. Your proxy strips the X-Forwarded-Proto header from all incoming requests, even when it contains a comma-separated list of protocols. In other words, if end users include that header in their requests, the proxy will discard it.
3. Your proxy sets the X-Forwarded-Proto header and sends it to Django, but only for requests that originally come in via HTTPS.

If any of those are not true, you should keep this setting set to None and find another way of determining HTTPS, perhaps via custom middleware.

I'm still processing that 😄 So I will probably come back to this PR tomorrow when I had a nights sleep over that.

``` Warning Modifying this setting can compromise your site’s security. Ensure you fully understand your setup before changing it. Make sure ALL of the following are true before setting this (assuming the values from the example above): 1. Your Django app is behind a proxy. 2. Your proxy strips the X-Forwarded-Proto header from all incoming requests, even when it contains a comma-separated list of protocols. In other words, if end users include that header in their requests, the proxy will discard it. 3. Your proxy sets the X-Forwarded-Proto header and sends it to Django, but only for requests that originally come in via HTTPS. If any of those are not true, you should keep this setting set to None and find another way of determining HTTPS, perhaps via custom middleware. ``` I'm still processing that 😄 So I will probably come back to this PR tomorrow when I had a nights sleep over that.
mhu reviewed 2024-11-20 10:39:07 +01:00
shimatta_kenkyusho/shimatta_kenkyusho/settings_production.py
@ -240,2 +239,4 @@
SECURE_SSL_REDIRECT = False
# allow detection of https behind "old" nginx
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
mhu commented 2024-11-20 10:39:07 +01:00
Owner
Copy Link

I don't get this. This should only be a problem, if django actually wants to check for HTTPS.
I don't need tha toption and everything looks fine.

Have you checked that Line #239 says SECURE_SSL_REDIRECT = False in your case as well when running?
If this is the case:

Can you have a look at your docker ps when running it from the docker compose setup and see if the container is "healthy"?
This health check uses a curl command to get a static HTTP OK response. This only works without https, because inside the container there is not https setup.

Can you also have a look at:
https://stackoverflow.com/questions/28001659/django-secure-proxy-ssl-header-requires-referer

This describes some other stuff and mentions a sort of redirect loop, I think you also experienced before, right?

I don't get this. This should only be a problem, if django actually wants to check for HTTPS. I don't need tha toption and everything looks fine. Have you checked that Line #239 says ` SECURE_SSL_REDIRECT = False` in your case as well when running? If this is the case: Can you have a look at your `docker ps` when running it from the docker compose setup and see if the container is "healthy"? This health check uses a curl command to get a static HTTP OK response. This only works without https, because inside the container there is not https setup. Can you also have a look at: https://stackoverflow.com/questions/28001659/django-secure-proxy-ssl-header-requires-referer This describes some other stuff and mentions a sort of redirect loop, I think you also experienced before, right?
mhu commented 2024-11-20 10:55:37 +01:00
Owner
Copy Link

https://medium.com/django-deployment/how-to-fix-djangos-https-redirects-in-nginx-63d304ddb19c

Tossing that into the mix as well...

https://medium.com/django-deployment/how-to-fix-djangos-https-redirects-in-nginx-63d304ddb19c Tossing that into the mix as well...
mhu commented 2024-11-20 14:56:43 +01:00
Owner
Copy Link

Okay, I think I found the root cause of the issue:

HttpRequest.is_secure(): Returns True if the request is secure; that is, if it was made with HTTPS.
Django isn’t magic here: it goes on a couple of clues as to what to answer there:
SECURE_PROXY_SSL_HEADER setting, if set.
For WSGI, the value of the "wsgi.url_scheme" environ key, otherwise.

So django either detects it from the WSGI or from the set header if the setting sis set.
I guess our container IPs are differntly random bricking that?!

I will do some further tests on my side and look, what the formwarded protocol looks like.

Okay, I think I found the root cause of the issue: > HttpRequest.is_secure(): Returns True if the request is secure; that is, if it was made with HTTPS. > Django isn’t magic here: it goes on a couple of clues as to what to answer there: > SECURE_PROXY_SSL_HEADER setting, if set. > For WSGI, the value of the "wsgi.url_scheme" environ key, otherwise. So django either detects it from the WSGI or from the set header if the setting sis set. I guess our container IPs are differntly random bricking that?! I will do some further tests on my side and look, what the formwarded protocol looks like.
mhu approved these changes 2024-11-21 00:49:34 +01:00
mhu commented 2024-11-21 00:50:00 +01:00
Owner
Copy Link

As I was finally able to reproduce all that stuff, it's okay.

As I was finally able to reproduce all that stuff, it's okay.
mhu merged commit b873b1fd0f into develop 2024-11-21 00:50:08 +01:00
mhu deleted branch sst/some-weird-stuff-with-docker 2024-11-21 00:50:08 +01:00
Sign in to join this conversation.
Reviewers
No reviewers
mhu
Labels
Clear labels   
Compat/Breaking

Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No Label
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mhu/shimatta-kenkyusho#22
No description provided.
Delete Branch "sst/some-weird-stuff-with-docker"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?