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 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 True

is 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 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 is ProxyPreserveHost 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 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

===========

1. 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.

2. 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 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

On 8/2/25 16:16, Mark wrote:

It fails for both domains on the server with the ACCOUNT_ADAPTER string in "settings.py" and the unmodified  "user_adapter.py".

This says to me that the "settings.py" is calling the "user_adapter.py" which, for some strange reason, is still trying to match a site(host) name.

I don't think that's it. I think it's earlier in the processing than that.

What happens if you put

ACCOUNT_ADAPTER = 'allauth.account.adapter.DefaultAccountAdapter'

in settings.py.

Also, what are the settings in your web server for proxying to Mailman.

I have tried this in a test installation with two domains and

SITE_ID = 0

ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'

and I have no issue accessing accounts/signup at either domain.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan