Can login at /admin, but cannot login at the account/login page.
Hi All, thanks for your contibution to opensource softwares. I have done the installation walkthrough on the wiki page (thanks to Brian Carpenter) and I am almost there. I can run the three services and they provide the relevant web interfaces (admin, postorius, hyperkitty). In comparison to the walkthrough, I did two changes; First, I used different port numbers , as it would otherwise conflict with other services on the server. Second, I disabled the social accounts authentification mechanisms. I am still running on sqllite, as I am still testing things (one task at a time).
Using my "superuser" credentials, I can log to the admin section in a fraction of a second. The server response time is less than one second. Once logged in, I can navigate through all the site as an authenticated user, including in the postorius pages related to list management. The services work normally.
However, if logout and attempt to login from the postorius website, I get a « 502 bad gateway » error after roughly 30 seconds. The logs in Systemctl for gunicorn register a "DIGEST-MD5 common mech free" error message and the nginx error logs just show a connection drop:
2021/08/12 18:11:09 [error] 26026#26026: *31 upstream prematurely closed connection while reading response header from upstream, client: [ip redacted], server: [domain redacted], request: "POST /accounts/login/ HTTP/2.0", upstream: "http://127.0.0.1:8006/accounts/login/", host: "[domain redacted]", referrer: "https://[domain redacted]/accounts/login/?next=/mailman3/lists/"
Two additional clues may help understanding what is going on:
1- If I attempt to login with improper credentials, the services respond normally, and I get the expected red box with "invalid credentials" message on the postorius page. It is only when proper credentials are given that the connection fails.
2- If I attempt to register a new email adress, the services also fail to respond (although with no DIGEST-MD5 message registered).
It thus seems to be a post "POST" problem, but what puzzles me is that it is not an issue for the admin page.
Below the relevant sections of my settings.py page. The skipped ([...]) sections are as in the walkthrough files. In particular, the AUTH_PASSWORD_VALIDATORS, the EMAIL_BACKEND are as is and the "USE_X_FORWARDED_HOST" is still commented.
##Settings.py [...] # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = '[redacted]'
# SECURITY WARNING: don't run with debug turned on in production! DEBUG = False
ADMINS = ( ('ME', 'my@email'), )
SITE_ID = 1
# Hosts/domain names that are valid for this site; required if DEBUG is False # See https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts ALLOWED_HOSTS = [ "localhost", # Archiving API from Mailman, keep it. "[domain]", # Add here all production URLs you may have. ]
# Mailman API credentials MAILMAN_REST_API_URL = 'http://localhost:8005' MAILMAN_REST_API_USER = '[redacted]' MAILMAN_REST_API_PASS = '[redacted]' MAILMAN_ARCHIVER_KEY = '[redacted]' MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1')
# Application definition
INSTALLED_APPS = ( 'hyperkitty', 'postorius', 'django_mailman3', # Uncomment the next line to enable the admin: 'django.contrib.admin', # Uncomment the next line to enable admin documentation: # 'django.contrib.admindocs', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount', #'django_mailman3.lib.auth.fedora', #'allauth.socialaccount.providers.openid', #'allauth.socialaccount.providers.github', #'allauth.socialaccount.providers.gitlab', #'allauth.socialaccount.providers.google', #'allauth.socialaccount.providers.facebook', #'allauth.socialaccount.providers.twitter', #'allauth.socialaccount.providers.stackexchange', )
[...] # Database # https://docs.djangoproject.com/en/1.8/ref/settings/#databases
DATABASES = { 'default': { # Use 'sqlite3', 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'. 'ENGINE': 'django.db.backends.sqlite3', # DB name or path to database file if using sqlite3. 'NAME': os.path.join(BASE_DIR, 'mailmansuite.db'), # The following settings are not used with sqlite3: 'USER': 'XXX', 'PASSWORD': 'XXX', # HOST: empty for localhost through domain sockets or '127.0.0.1' for # localhost through TCP. 'HOST': '', # PORT: set to empty string for default. 'PORT': '', # OPTIONS: for mysql engine only, do not use with other engines. # 'OPTIONS': {'charset': 'utf8mb4'} # Enable utf8 4-byte encodings. } } [...]
# Password validation # https://docs.djangoproject.com/en/1.9/ref/settings/#auth-password-validators
AUTH_PASSWORD_VALIDATORS = [ { 'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator', }, { 'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator', }, { 'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator', }, { 'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator', }, ]
# Internationalization # https://docs.djangoproject.com/en/1.8/topics/i18n/
LANGUAGE_CODE = 'fr'
TIME_ZONE = 'America/New_York'
[...]
# If you enable internal authentication, this is the address that the emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#default-from-email # DEFAULT_FROM_EMAIL = "mailing-lists@you-domain.org" DEFAULT_FROM_EMAIL = 'username@domain'
# If you enable email reporting for error messages, this is where those emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SERVER_EMAIL # SERVER_EMAIL = 'root@your-domain.org' SERVER_EMAIL = 'username@domain'
# Change this when you have a real email backend EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
[...]
# # Social auth # AUTHENTICATION_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', 'allauth.account.auth_backends.AuthenticationBackend', )
# Django Allauth ACCOUNT_AUTHENTICATION_METHOD = "username_email" ACCOUNT_EMAIL_REQUIRED = True ACCOUNT_EMAIL_VERIFICATION = "mandatory" # You probably want https in production, but this is a dev setup file ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https" ACCOUNT_UNIQUE_EMAIL = True
# # Asynchronous tasks # Q_CLUSTER = { 'timeout': 300, 'save_limit': 100, 'retry':360, 'orm': 'default', }
[...] # Only display mailing-lists from the same virtual host as the webserver FILTER_VHOST = True
POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8006'
## (End of settings.py)
I'm happy to provide additional information if it can help.
Best,
Pier-André
I'm sorry, I'm in a "second vaccination" fog at the moment (mending but concentration lasts only about 10 minutes), so I'll answer what I know offhand since Abhilash is busy and Mark is probably offline for vacation by now. Perhaps later somebody can give a fuller answer.
pabsta@gmail.com writes:
In comparison to the walkthrough, I did two changes; First, I used different port numbers , as it would otherwise conflict with other services on the server.
Thank you for the very precise description. It's very helpful.
Second, I disabled the social accounts authentification mechanisms.
This should not be a problem since you disabled only the providers (I think the socialauth base module is required even if you don't use it.)
I am still running on sqllite, as I am still testing things (one task at a time).
This should be no problem.
Using my "superuser" credentials, I can log to the admin section in a fraction of a second.
If you mean the django admin page https://localhost:800something/admin, that doesn't involve any part of Mailman at all.
However, if logout and attempt to login from the postorius website, I get a « 502 bad gateway » error after roughly 30 seconds. The logs in Systemctl for gunicorn register a "DIGEST-MD5 common mech free" error message
I would guess this is also just a connection drop because it doesn't receive the expected response within timeout.
and the nginx error logs just show a connection drop:
2021/08/12 18:11:09 [error] 26026#26026: *31 upstream prematurely closed connbection while reading response header from upstream, client: [ip redacted], server: [domain redacted], request: "POST /accounts/login/ HTTP/2.0", upstream: "http://127.0.0.1:8006/accounts/login/", host: "[domain redacted]", referrer: "https://[domain redacted]/accounts/login/?next=/mailman3/lists/" a >
1- If I attempt to login with improper credentials, the services respond normally, and I get the expected red box with "invalid credentials" message on the postorius page. It is only when proper credentials are given that the connection fails.
The only thing I can think of is that having sucessfully logged in, Postorius can't find Mailman core to populate your user page. That would explain why an invalid login (which is entirely within Postorius and Django) proceeds as expected, but a valid login would fail so spectacularly.
# Mailman API credentials MAILMAN_REST_API_URL = 'http://localhost:8005'
Is Mailman core listening on localhost:8005? Is there possibly a conflict with something else on that port?
Steve
On 8/14/21 9:34 PM, Stephen J. Turnbull wrote:
I'm sorry, I'm in a "second vaccination" fog at the moment (mending but concentration lasts only about 10 minutes), so I'll answer what I know offhand since Abhilash is busy and Mark is probably offline for vacation by now.
Not quite, but very soon.
pabsta@gmail.com writes:
However, if logout and attempt to login from the postorius website, I get a « 502 bad gateway » error after roughly 30 seconds. The logs in Systemctl for gunicorn register a "DIGEST-MD5 common mech free" error message
I would guess this is also just a connection drop because it doesn't receive the expected response within timeout.
I'm sure that's right.
and the nginx error logs just show a connection drop:
2021/08/12 18:11:09 [error] 26026#26026: *31 upstream prematurely closed connbection while reading response header from upstream, client: [ip redacted], server: [domain redacted], request: "POST /accounts/login/ HTTP/2.0", upstream: "http://127.0.0.1:8006/accounts/login/", host: "[domain redacted]", referrer: "https://[domain redacted]/accounts/login/?next=/mailman3/lists/" a >
I see in the above upstream: "http://127.0.0.1:8006/accounts/login/",
but in your settings
ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https"
I suspect you may be getting a redirect from http to https which is losing POST data and you need to change
proxy_pass http://127.0.0.1:8006;in your nginx configuration to
proxy_pass https://127.0.0.1:8006;or set
ACCOUNT_DEFAULT_HTTP_PROTOCOL = "http"
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Aug 15, 2021, at 11:33 AM, Mark Sapiro <mark@msapiro.net> wrote:
On 8/14/21 9:34 PM, Stephen J. Turnbull wrote:
I'm sorry, I'm in a "second vaccination" fog at the moment (mending but concentration lasts only about 10 minutes), so I'll answer what I know offhand since Abhilash is busy and Mark is probably offline for vacation by now.
Not quite, but very soon.
pabsta@gmail.com writes:
However, if logout and attempt to login from the postorius website, I get a « 502 bad gateway » error after roughly 30 seconds. The logs in Systemctl for gunicorn register a "DIGEST-MD5 common mech free" error message
I would guess this is also just a connection drop because it doesn't receive the expected response within timeout.
I'm sure that's right.
and the nginx error logs just show a connection drop:
2021/08/12 18:11:09 [error] 26026#26026: *31 upstream prematurely closed connbection while reading response header from upstream, client: [ip redacted], server: [domain redacted], request: "POST /accounts/login/ HTTP/2.0", upstream: "http://127.0.0.1:8006/accounts/login/", host: "[domain redacted]", referrer: "https://[domain redacted]/accounts/login/?next=/mailman3/lists/" a >
I see in the above
upstream: "http://127.0.0.1:8006/accounts/login/",but in your settingsACCOUNT_DEFAULT_HTTP_PROTOCOL = "https"
I suspect you may be getting a redirect from http to https which is losing POST data and you need to change
proxy_pass http://127.0.0.1:8006;in your nginx configuration to
proxy_pass https://127.0.0.1:8006;or set
ACCOUNT_DEFAULT_HTTP_PROTOCOL = "http"
This configuration actually doesn’t really dictate connection related configs, but mostly, the protocol to use in the emails generated by django-allauth to verify email and such. It shouldn’t have affect on the problem IMO.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
On Aug 14, 2021, at 9:34 PM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
I'm sorry, I'm in a "second vaccination" fog at the moment (mending but concentration lasts only about 10 minutes), so I'll answer what I know offhand since Abhilash is busy and Mark is probably offline for vacation by now. Perhaps later somebody can give a fuller answer.
pabsta@gmail.com writes:
In comparison to the walkthrough, I did two changes; First, I used different port numbers , as it would otherwise conflict with other services on the server.
Thank you for the very precise description. It's very helpful.
Second, I disabled the social accounts authentification mechanisms.
This should not be a problem since you disabled only the providers (I think the socialauth base module is required even if you don't use it.)
I am still running on sqllite, as I am still testing things (one task at a time).
This should be no problem.
Using my "superuser" credentials, I can log to the admin section in a fraction of a second.
If you mean the django admin page https://localhost:800something/admin, that doesn't involve any part of Mailman at all.
However, if logout and attempt to login from the postorius website, I get a « 502 bad gateway » error after roughly 30 seconds. The logs in Systemctl for gunicorn register a "DIGEST-MD5 common mech free" error message
I would guess this is also just a connection drop because it doesn't receive the expected response within timeout.
and the nginx error logs just show a connection drop:
2021/08/12 18:11:09 [error] 26026#26026: *31 upstream prematurely closed connbection while reading response header from upstream, client: [ip redacted], server: [domain redacted], request: "POST /accounts/login/ HTTP/2.0", upstream: "http://127.0.0.1:8006/accounts/login/", host: "[domain redacted]", referrer: "https://[domain redacted]/accounts/login/?next=/mailman3/lists/" a >
1- If I attempt to login with improper credentials, the services respond normally, and I get the expected red box with "invalid credentials" message on the postorius page. It is only when proper credentials are given that the connection fails.
The only thing I can think of is that having sucessfully logged in, Postorius can't find Mailman core to populate your user page. That would explain why an invalid login (which is entirely within Postorius and Django) proceeds as expected, but a valid login would fail so spectacularly.
This would be my guess too, although, it will show MailmanApiError in logs.
Do note that that gunicorn logs don’t have all the logs from exceptions raised in Postorius, for that, you want to file the location of the ‘postorius’ or ‘root’ logger in your settings.py (I couldn’t find that, it seems like you skipped those).
So, I’d expect some error or something in the logs if this isn’t the actual case.
-- thanks, Abhilash Raj (maxking)
Hello guys, I just came across the same problem. Has any of you found a proper solution for this one. Not able to find out why I'm getting the same error. Something I noticed is that it works fine when I set the configuration to DEBUG mode by setting DEBUG=True in /etc/mailman3/settings.py
gcmuni@gmail.com writes:
Hello guys, I just came across the same problem. Has any of you found a proper solution for this one. Not able to find out why I'm getting the same error.
First, what account are you trying to log in? Then, what is the error, or response, from Postorius?
As far as I know, all Postorius users are Django users, but not all Django users are Postorius users. Are you sure the user you are trying to log in is registered with Postorius?
Something I noticed is that it works fine when I set the configuration to DEBUG mode by setting DEBUG=True in /etc/mailman3/settings.py
Not sure why that would be, although I can imagine that DEBUG=True would give admins additional privilege only in that situation.
Steve
Actually it doesn't let me in to the login page / sign up page (the HTTP requests hangs until it times out). The URL I'm trying to access is http://localhost/accounts/login/?next=/mailman3/lists/ or http://localhost:8002/accounts/signup/?next=/mailman3/lists/ eventually Nginx returns a "502 Gateway timeout error"
I followed the instructions here https://docs.mailman3.org/en/latest/install/virtualenv.html but I changed my Nginx config shown below as I just want it to run on HTTP
server {
listen 80 default_server; listen [::]:80 default_server;
server_name _; 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;
} }
I'm sticking to DEBUG=True in the meantime as I don't require a production deployment yet.
The Django admin dashboard works fine for both DEBUG set to True or False
Gonzalo Cardenas writes:
Actually it doesn't let me in to the login page / sign up page (the HTTP requests hangs until it times out). The URL I'm trying to access is http://localhost/accounts/login/?next=/mailman3/lists/ or http://localhost:8002/accounts/signup/?next=/mailman3/lists/ eventually Nginx returns a "502 Gateway timeout error"
The second URL appears to presume Postorius is actually running on port 8002, but this
location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr;
tells nginx to proxy to port 8000. I don't use nginx or uwsgi myself (I use Apache and mod_wsgi) so I am not very confident. But you need to make sure that all of the configuration files use the same port.
I don't remember if any of the webservers suffered from this, but some programs don't map 127.0.0.1 to localhost. If any of the configs specify localhost for the Postorius URI, you could try using 127.0.0.1 instead.
If making all these port configurations consistent doesn't do the trick, please post your mailman-web settings.py, uswgi config, and nginx config. You can substitute fake domain names and IP addresses if you're worried about privacy of your configs, but make sure that (1) if the configs specify several IPs or several domain names, you distinguish them in your fake versions, and (2) always substitute the same fake IP/name for a given real IP/name.
Steve
participants (7)
-
Abhilash Raj -
gcmuni＠gmail.com -
Gonzalo Cardenas
-
Mark Sapiro -
pabsta＠gmail.com -
Stephen J. Turnbull -
Stephen J. Turnbull