Thomas Krichel writes:

I am using apache to run the web interface, and my Postel port, and I have the proxy routs [some routes omitted] ProxyPass "/accounts" "http://127.0.0.1:4386/accounts" is broken

What does "is broken" mean here? Well, since I have debug on, GET "http://127.0.0.1:4386/accounts"

This isn't going to match as far as I can see (but see comments below about customized systems). Here are the routes stock Postorius serves from postorius/urls.py:

    r'^accounts/subscriptions/$',
    r'^accounts/per-address-preferences/$',
    r'^accounts/per-subscription-preferences/$',
    r'^accounts/mailmansettings/$',
    r'^accounts/list-options/(?P<member_id>[^/]+)/$',

(Note: I usually copy that file to /etc/mailman3/urls.py in case I make changes. In particular I usually comment out the ^postorius and ^hyperkitty routes.) But in your case, I don't know what's in

| Using the URLconf defined in <code>mailman_web.urls</code>,

You have to tell us what's in that file.

reminded that I appended

del ACCOUNT_AUTHENTICATION_METHOD ACCOUNT_LOGIN_METHODS = {'email', 'username'} del ACCOUNT_EMAIL_REQUIRED ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*']

That has nothing to do with URL routing. URL routing is all defined in the URLconf, which is usually in a file named "urls.py", but you can change that name and mess with the routes if you want. It seems that you did.

Ideally an error like this should be shown to the user.

That's a Django decision. We're not going to change it. I don't think it's very useful to show it though, since the user can't do anything about it. They have to complain to the sysadmin either way.

Instead it leads to a endlessly repeated requests for users to verify their email address, as seen in my live system at say

https://lists.repec.info/accounts/confirm-email/

That route doesn't exist anywhere in stock Postorius. It seems to be provided by the allauth package (allauth/account/urls.py, but I'm not sure how that gets added to the URLconf. Presumably that's from some app or middleware that you should have configured in settings.py. (That URLconf doesn't match a bare /account or /account/, either.)

In my no-social-auth installation I apparently needed the following at the end of INSTALLED_APPS:

'allauth',
'allauth.account',
'allauth.socialaccount',

and this at the beginning of MIDDLEWARE

'allauth.account.middleware.AccountMiddleware',

(these are from mailman_web/settings/base.py). You might be able to delete 'allauth.socialaccount', but I'm pretty sure mailman-web doesn't work without the other three.

These have no CSS, pointing to an apache missconfiguration

There's no linking element in the output you presented. Without a link to the CSS file (or immediate style="..." attributes), there won't be any CSS.

For what it's worth, here is my current apache configuration

That looks OK to me. I don't see a misconfiguration there, but you have a customized system. We'll help you with it if we can, but you need to provide the information we need.

| LogLevel debug | ErrorLog /var/log/apache2/lists.repec.info_error.log | | CustomLog /var/log/apache2/lists.repec.info_access.log combined | ServerSignature On

What's in those logs that's relevant to your queries?

Steve

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan