Hi,
GNU Mailman 3.3.10 (Tom Sawyer) VENV installation
Disabling the Account "Sign-up" globally can be done by adding the following to "/etc/mailman3/settings.py".
ACCOUNT_ADAPTER =
'django_mailman3.views.user_adapter.DisableSignupAdapter'
I have several domains on the server. Is it possible to disable the Sign-up for only one of the domains ?
Regards, Mark
On 7/30/25 16:10, Mark wrote:
Disabling the Account "Sign-up" globally can be done by adding the following to "/etc/mailman3/settings.py".
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
I have several domains on the server. Is it possible to disable the Sign-up for only one of the domains ?
Anything is possible, it's only code ;) You could make your own user_adapter.py which is modified like ``` --- a/django_mailman3/views/user_adapter.py +++ b/django_mailman3/views/user_adapter.py @@ -31,7 +31,10 @@ class DisableSignupAdapter(DefaultAccountAdapter): """ def is_open_for_signup(self, req): - return False + if req.META.HTTP_HOST == 'the.domain': + return False + else: + return super().is_open_for_signup(self, req) class EnableSocialSignupAdapter(DefaultSocialAccountAdapter): ``` and set that as the ACCOUNT_ADAPTER. This depends on whatever is proxying to Django setting the appropriate HTTP_HOST header. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2025-07-31 03:31, Mark Sapiro wrote:
Anything is possible, it's only code ;)
You could make your own user_adapter.py which is modified like
and set that as the ACCOUNT_ADAPTER. This depends on whatever is proxying to Django setting the appropriate HTTP_HOST header.
Thank you Mark. It's so close. After wrangling your solution a bit it's working a treat on my test server (wrangled solution below) .
When I add it to the production server (same OS, MM installation, etc) I'm getting a "Bad gateway" error page and the log reports ...
... raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist.
I cannot for the life of me get my head around that. I suspect it's something to do with what you said -- "whatever is proxying to Django setting the appropriate HTTP_HOST header." -- which I don't understand.
Any additional advice gratefully received.
================================== /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py
COMMENT OUT THESE 2 LINES...
# def is_open_for_signup(self, req): # return False
REPLACE WITH THE FOLLOWING...
def is_open_for_signup(self, req):
if req.META['HTTP_HOST'] == 'lists.mydomain.com':
return False
else:
return True================================== /etc/mailman3/settings.py
Append the following ...
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
================================== systemctl restart mailman3 systemctl restart mailmanweb
On 7/31/25 17:54, Mark wrote:
Thank you Mark. It's so close. After wrangling your solution a bit it's working a treat on my test server (wrangled solution below) .
When I add it to the production server (same OS, MM installation, etc) I'm getting a "Bad gateway" error page and the log reports ...
... raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist.
That error will occur when settings.py contains
SITE_ID = 0
and the host in the http request is not one of the hosts in the django_site table in the database or in Sites in the Django admin web UI.
Is that possibly the case here? In any case, if the change to /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py that you report below is the only thing that changed from a working installation, I don't see how that can affect this.
Is there a complete traceback preceding the log snippet you report. If so, what is it?
I cannot for the life of me get my head around that. I suspect it's something to do with what you said -- "whatever is proxying to Django setting the appropriate HTTP_HOST header." -- which I don't understand.
This is in the configuration of the web server. It should be configured
to pass the host of the incoming request to the proxy target in the
HTTP_HOST header. In nginx this is proxy_set_header Host $host;. In
apache it is ProxyPreserveHost On, but again the change to
user_adapter shouldn't affect this.
Any additional advice gratefully received.
================================== /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py
COMMENT OUT THESE 2 LINES...
# def is_open_for_signup(self, req): # return False
REPLACE WITH THE FOLLOWING...
def is_open_for_signup(self, req): if req.META['HTTP_HOST'] == 'lists.mydomain.com':
I had
if req.META.HTTP_HOST == 'lists.mydomain.com':which as you discovered is wrong. What you have is correct.
return False else: return True
And here I had
return super().is_open_for_signup(self, req)which should return the is_open_for_signup result from allauth.account.adapter.DefaultAccountAdapter but since that result is an unconditional True, what you have is OK too.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7/31/25 18:37, Mark Sapiro wrote:
And here I had
return super().is_open_for_signup(self, req)
which should return the is_open_for_signup result from allauth.account.adapter.DefaultAccountAdapter but since that result is an unconditional True, what you have is OK too.
Actually, that too was wrong. It should have been
return super().is_open_for_signup(req)but that is now moot as
return Trueis fine.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2025-08-01 02:46, Mark Sapiro wrote:
And here I had
return super().is_open_for_signup(self, req)
which should return the is_open_for_signup result from allauth.account.adapter.DefaultAccountAdapter but since that result is an unconditional True, what you have is OK too.
Actually, that too was wrong. It should have been
return super().is_open_for_signup(req)but that is now moot as
return Trueis fine.
Ahhh. Thank you for letting me know that. I had used "return True" in an act of desperation. Is good to be shown how to do it right.
:-)
On 2025-08-01 01:37, Mark Sapiro wrote:
raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist.
That error will occur when settings.py contains
SITE_ID = 0
and the host in the http request is not one of the hosts in the django_site table in the database or in Sites in the Django admin web UI. Is that possibly the case here?
The SITE_ID and database table check okay. The SITE_ID is supposed to be "0"? No?
SITE_ID Test server - settings.py: SITE_ID = 0 Prod server - settings.py: SITE_ID = 0
HTTP_HOST
Test server DB - mailmanweb.django_site table: domain and name fields OK
Prod server DB - mailmanweb.django_site table: domain and name fields
OK
And the hosts are displayed in Sites in the admin UI.
I also checked the ALLOWED_HOSTS in the Test and Prod servers. Both have:
... "localhost", "127.0.0.1", "<IP4 ADDRESS OF HOST>", "<MY.DOMAIN.COM>" "<OTHER.DOMAINNAME.COM>", ...
Is there a complete traceback preceding the log snippet you report. If so, what is it?
The traceback does suggest that the SITE does not exist...
======================= TRACEBACK =====================
Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.11/site-packages/django/contrib/sites/models.py", line 39, in _get_site_by_request SITE_CACHE[host] = self.get(domain__iexact=host) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/db/models/manager.py", line 87, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/db/models/query.py", line 637, in get raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist.
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/postorius/views/list.py", line 1158, in list_index return render( ^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/shortcuts.py", line 24, in render content = loader.render_to_string(template_name, context, request, using=using) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/template/loader.py", line 62, in render_to_string return template.render(context, request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/template/backends/django.py", line 61, in render return self.template.render(context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/template/base.py", line 173, in render with context.bind_template(self): File "/usr/lib/python3.11/contextlib.py", line 137, in __enter__ return next(self.gen) ^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/template/context.py", line 254, in bind_template updates.update(processor(self.request)) ^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/context_processors.py", line 32, in common context["site_name"] = get_current_site(request).name ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/contrib/sites/shortcuts.py", line 16, in get_current_site return Site.objects.get_current(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/contrib/sites/models.py", line 61, in get_current return self._get_site_by_request(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/contrib/sites/models.py", line 45, in _get_site_by_request SITE_CACHE[domain] = self.get(domain__iexact=domain) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/db/models/manager.py", line 87, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/django/db/models/query.py", line 637, in get raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist. ERROR 2025-08-01 05:21:46,176 2030595 django.request Internal Server Error: /owa/auth/logon.aspx ERROR 2025-08-01 05:21:46,176 2030595 django.request Internal Server Error: /owa/auth/logon.aspx
============= END TRACEBACK =================
... -- "whatever is proxying to Django setting the appropriate HTTP_HOST header." -- which I don't understand.
This is in the configuration of the web server. It should be configured to pass the host of the incoming request to the proxy target in the HTTP_HOST header. In nginx this is
proxy_set_header Host $host;. In apache it isProxyPreserveHost On, but again the change to user_adapter shouldn't affect this.
That all looks good for both the Prod and Test servers.
... location /static/ { alias /opt/mailman/web/static/; }
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}...
On 7/31/25 23:00, Mark wrote:
The traceback does suggest that the SITE does not exist...
Yes.
Please confirm that the issue only occurs with the modified /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py and does not occur with the original .../user_adapter.py.
Also, prior to installing the modified /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py did you have
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
in your settings or did you only add that with the modified .../user_adapter.py
I.e., I'm trying to determine if there is some issue with the modified ../user_adapter.py or if the issue does not involve the modification, but rather just the setting of ACCOUNT_ADAPTER
Also, when does this error occur? Does it occur an all web access to the site or only on access to the accounts/signup page? and does the host in the https request make a difference?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2025-08-01 19:40, Mark Sapiro wrote:
Please confirm that the issue only occurs with the modified /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py and does not occur with the original .../user_adapter.py.
Hi Mark,
In working through this I reverted the test server (which had the working "Disable") back to original, then re-applied the changes, and now I'm getting the same errors as on the Production server.
I think it might be me screwing up somewhere. It's doing my head in today so I'll sleep on it and have another crack at it tomorrow.
STEPS TAKEN
===========
- Reset the "Test" server back to original.
(a) I put the original "user_adapter.py" back in place. It contains: ... def is_open_for_signup(self, req): return False ...
(b) Ensured that "settings.py" had the following completely removed: ... ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter' ...
(c) systemctl restart mailman3 systemctl restart mailmanweb
(d) Reloaded browser with "lists" page for each domain and clicked "SignUp" on each.
Result: As expected, both domains correctly displayed their SignUp pages.
- Made the following changes to the "Test" server.
(a) Edited /opt/mailman/venv/lib/python3.11/site-packages/django_mailman3/views/user_adapter.py
It now contains: ... # def is_open_for_signup(self, req): # return False
def is_open_for_signup(self, req):
if req.META['HTTP_HOST'] == 'lists.MYDOMAIN.COM':
return False
else:
return True...
(b) Appended to - /etc/mailman3/settings.py - the following:
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
(c) systemctl restart mailman3 systemctl restart mailmanweb
Result: 502 Bad Gateway page and log shows ... raise self.model.DoesNotExist( django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist.
===========
On 2025-08-01 19:40, Mark Sapiro wrote:
I.e., I'm trying to determine if there is some issue with the modified ../user_adapter.py or if the issue does not involve the modification, but rather just the setting of ACCOUNT_ADAPTER
If I leave the modified "user_adapter.py" in place, and remove the
ACCOUNT_ADAPTER string from the "settings.py" file all is well ie. the
SignUp pages display as they should.
On 8/1/25 17:43, Mark wrote:
If I leave the modified "user_adapter.py" in place, and remove the ACCOUNT_ADAPTER string from the "settings.py" file all is well ie. the SignUp pages display as they should.
What happens if you put the unmodified "user_adapter.py" in place and add the ACCOUNT_ADAPTER string to the "settings.py" file.
I.e. I'm trying to determine if the issue is related to the modifications or if it occurs even with the unmodified "user_adapter.py" with the ACCOUNT_ADAPTER string added to the "settings.py" file.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Mark -
Mark Sapiro