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 _______________________________________________ Mailman-users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/[email protected]/message/EOHERZG2XZQXFFSUMFVLYL2BPN44TDCF/ This message sent to [email protected]
