El 27/10/22 a las 5:48, Mark Sapiro escribió:

On 10/26/22 04:33, Guillermo Hernandez (Oldno7) via Mailman-users wrote:

...

I did it via pip and all seems to be working, but when I try to discard or accept any message via postorius it shows a Forbidden 403 error CSRF verification failed.

In my settings.py I have commented out these variables:

# Other security settings # SECURE_SSL_REDIRECT = True # If you set SECURE_SSL_REDIRECT to True, make sure the SECURE_REDIRECT_EXEMPT # contains at least this line: # SECURE_REDIRECT_EXEMPT = [ #     "archives/api/mailman/.*",  # Request from Mailman. #     ] # SESSION_COOKIE_SECURE = True # SECURE_CONTENT_TYPE_NOSNIFF = True # SECURE_BROWSER_XSS_FILTER = True # CSRF_COOKIE_SECURE = True # CSRF_COOKIE_HTTPONLY = True # X_FRAME_OPTIONS = 'DENY'

I've been messing with them whith no results. It's like it lacked some value in some template...

It's not an issue with the code per se or the templates. These updates are all installed on mail.python.org and lists.mailman3.org and are working fine.

After upgrading did you run

django-admin collectstatic --clear django-admin compress django admin migrate

Since I made all the mailman3 enviroment wide server open (not using venv) I already executed the migration doing a

su -m mailman3 -c "python3 manage.py collectstatic" su -m mailman3 -c "python3 manage.py migrate"

Being mailman3 the user who runs all of mailman3 related stuff

I had problems doing the migrate part, showing an error of lacking perms. I solved it running the migration under root (I know it could be trouble after, but...)

After that the compress part showed errors... but the postorius web maintenance was working well except for the CSRF error verification. I will trace the compress errors and will try to find the problem later.

With your point to the CSRF_TRUSTED_ORIGINS parameter, I can now do the accept or discard part of a receiving message to the lists (I put below the config that is working for me).

All seems to be working now flawlessly.

Thanks once again for your guidance.

############ SESSION_COOKIE_SECURE = True SECURE_CONTENT_TYPE_NOSNIFF = True SECURE_BROWSER_XSS_FILTER = True CSRF_COOKIE_SECURE = True CSRF_COOKIE_HTTPONLY = True X_FRAME_OPTIONS = 'DENY' # CSRF_TRUSTED_ORIGINS = [ "https://*.mydomain-example.xxx", "https://mydomain-example", "https://mydomain", ] ############

If you have and it doesn't help, you probably need to add CSRF_TRUSTED_ORIGINS to your settings.py.

See https://docs.djangoproject.com/en/4.1/ref/settings/#csrf-trusted-origins and note the differences between Django <4.0 and >=4.0.

--

Mailman's content filtering has removed the following MIME parts from this message.

Content-Type: image/png Name: firma-GHP-emails.png

Replaced multipart/alternative part with first alternative.

El 27/10/22 a las 21:39, Mark Sapiro escribió:

On 10/27/22 03:04, Guillermo Hernandez (Oldno7) via Mailman-users wrote:

...

Since I made all the mailman3 enviroment wide server open (not using venv) I already executed the migration doing a

su -m mailman3 -c "python3 manage.py collectstatic" su -m mailman3 -c "python3 manage.py migrate"

Being mailman3 the user who runs all of mailman3 related stuff

I had problems doing the migrate part, showing an error of lacking perms. I solved it running the migration under root (I know it could be trouble after, but...)

It would be much better to identify the problem files/directories and adjust their ownership. It is possible that running stuff as root in the past left things owned by root causing the issue.

The problem was in the intent of execute one of the migrate parts and showed about python files. I'm pretty sure that I've been very carefull not running things as root before as I know it can mess all up. But this time it was an dead end and I needed to go through.

In a few days I will upgrade another server. I will document the error if I find it again.

...

After that the compress part showed errors... but the postorius web maintenance was working well except for the CSRF error verification. I will trace the compress errors and will try to find the problem later.

Do you have COMPRESS_ENABLED = True in your settings? If that's not the issue, it may be in the settings for COMPRESS_PRECOMPILERS

I will try to trace it and comment what I find.

Thaks a lot for your support.

--

Mailman's content filtering has removed the following MIME parts from this message.

Content-Type: image/png Name: firma-GHP-emails.png

Replaced multipart/alternative part with first alternative.

El 28/10/22 a las 9:18, Guillermo Hernandez (Oldno7) via Mailman-users escribió:

El 27/10/22 a las 21:39, Mark Sapiro escribió:

...

...

After that the compress part showed errors... but the postorius web maintenance was working well except for the CSRF error verification. I will trace the compress errors and will try to find the problem later.

Do you have COMPRESS_ENABLED = True in your settings? If that's not the issue, it may be in the settings for COMPRESS_PRECOMPILERS

While I'm tracing the problem out, this is the configuration I had working and the error it shows after upgrade:

<------- snip of settings.py>

# COMPRESS_PRECOMPILERS = ( ('text/less', 'lessc {infile} {outfile}'), ('text/x-scss', 'sassc -t compressed {infile} {outfile}'), ('text/x-sass', 'sassc -t compressed {infile} {outfile}'), ) # On a production setup, setting COMPRESS_OFFLINE to True will bring a # significant performance improvement, as CSS files will not need to be # recompiled on each requests. It means running an additional "compress" # management command after each code upgrade. # http://django-compressor.readthedocs.io/en/latest/usage/#offline-compression #### activo compresion 18/12/20 COMPRESS_OFFLINE = True ###COMPRESS_OFFLINE = False <---------- end snip>

And below is the error it shows:

/usr/local/mailman3 # su -m mailman3 -c "python3 manage.py compress" Traceback (most recent call last): File "/usr/local/mailman3/manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 279, in fetch_command klass = load_command_class(app_name, subcommand) File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 49, in load_command_class return module.Command() File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 274, in __init__ raise TypeError("requires_system_checks must be a list or tuple.") TypeError: requires_system_checks must be a list or tuple.

After searching around, I've got a hint of what can be happening. It seems a variable has changed in Django 4.1 its nature from boolean to a tuple

https://github.com/painless-software/django-probes/issues/24

I've upgraded another server with mailman3 lists, with the same config listed above, and it shows the same error in the "compress" part. I'm not sure where to set the requires_system_checks variable as in one of the comments of the link, and as it doesn't seems to break anything more, I will wait for more info before trying to avoid it. I'm sure it will have some repercusion on the performance, but I'll have to live with it.

Thanks again for your supporting advices.

--

Mailman's content filtering has removed the following MIME parts from this message.

Content-Type: image/png Name: firma-GHP-emails.png

Replaced multipart/alternative part with first alternative.