Christian Schneider writes: > did you manage to disable the local registration (with django > accounts)? I am trying to get rid of these locally registered > accounts as well.
The easist way to do this is to require SSO authentication to access webapps (this can be done in the front-end webserver), then use the identity provider to pass the authenticated user to Django. This can be done with a small custom extension to Django, and no modifications to code provided by Mailman or Django. Just registering the extension in the usual way. > (A list member can be any (external) user...I only care about > moderators/admins and moderators) This is very hard. Django authenticates *users*, users possess *roles*, and roles are authorized to access *resources*. However, owners can add roles to other users to make them moderators or even owners -- but this cannot trigger a change in the users' authentication process. So if owner A decides to make external user B a moderator, B will still authenticate however they did previously. Of course you can decide you trust all your owners and superusers not to do that. I'm just saying if they decide to do such a thing nothing in Mailman suite will stop them. > SOCIALACCOUNT_ONLY = True > ACCOUNT_EMAIL_VERIFICATION = EmailVerificationMethod.NONE > ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter' I don't think these settings do what you want (but I'm not a Django expert). In particular, you must disable all "unofficial" socialauth providers, which is unlikely to make your users happy. Also, I think this disables web signups and account management for everyone who isn't in your official identity provider. Finally, I think EMAIL_VERIFICATION refers to the normal process of sending a one-time key to the address, to confirm that the anonymous person who is trying to sign up the email can read that mailbox, not to login authentication. If so, that would be bad, as anyone could claim any email address. (Could be wrong, though.) > Is there any way to get approach (only sso-authorized > owners/admins/moderators) working? If you're going to allow "external" users, the approaches that pretty clearly will work require substantial and tricky code changes. It might be possible to mask the "administrative" links in the front-end webserver and require SSO authentication to "see" them, but that's never a very robust solution. If you're willing to manage identities of all users, it's straightforward. -- 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 -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-le...@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/FFYBINM5NIMJQHZNHQH27N76UNQ3WU4G/ This message sent to arch...@mail-archive.com
