>In that case, how should this address be validated? Should Postorius
>consider that the login system always validates addresses and set them
>as
>verified in Mailman? Should it ask mailman to verify the email
>addresses
>when it encounters a user's un-verified address? This does not seem
>possible in REST at the moment (unless I missed it), and should be
>protected against multiple checks.
>
>Ideas?
I started a thread about this a couple of months back. I was asking about what authentication system to switch to, since persona is being dropped. I found a couple of solutions and have my personal favorite: django-allauth
I have a merge request pending that adds basic functionality for it in postorius. I think that it's better than python-social-auth that hyperkitty is currently using.
Short version: it supports both external (social) and internal (django) auth systems and offers options to combine/switch between them . Allauth provides Signals that I used to verify the addresses in Mailman.
The link to my merge request:
https://gitlab.com/mailman/postorius/merge_requests/130
The link to my previous post:
https://mail.python.org/pipermail/mailman-developers/2016-January/025338.ht…
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Apr 06, 2016, at 06:08 PM, Aurelien Bompard wrote:
>In that case, how should this address be validated? Should Postorius
>consider that the login system always validates addresses and set them as
>verified in Mailman? Should it ask mailman to verify the email addresses
>when it encounters a user's un-verified address? This does not seem
>possible in REST at the moment (unless I missed it), and should be
>protected against multiple checks.
This is why POST on members (i.e. create a subscription) has a pre_verified
flag, which defaults to False. The core already has a subscription workflow
to send the address a confirmation email if the subscribing address is not
already verified, and pre_verified is False.
(It will send a similar confirmation email if pre_confirmed is False and the
mailing list is set to confirm or confirm_then_moderate.)
By default, confirmation can only effectively happen by email reply, but the
intent is that you could modify the confirm.txt template[1] to include the
appropriate link back into Postorius which would effect the same verification
step as a mail-back. This link would POST to <api>/addresses/<email>/verify
to verify the user's email address.
Thinking about it the terms you describe above, I guess there's another
workflow that isn't directly covered. When Postorius creates the user, an
address is also created and linked to the user, but it cannot be set as the
preferred address until it's verified. I can see where you might want to send
the verification email at some point before a subscription event, so that the
linked address gets verified and thus could be set as their preferred
address. If that's a use case you think we need, do file a bug. I don't
think it would be too difficult to implement.
Cheers,
-Barry
[1] Or w.r.t. GL issue #112, set a 'confirm.txt' template URL.
Hey people,
Mailman has the notion of "verified" email addresses. When a user is
created / registered in Postorius, a Mailman user can be created. It's off
by default but it seems like a logical thing to do.
This user will be created when the client visits the user profile or
preferences pages anyway, because it needs it in Mailman at that point.
However, the address that the user is created with is not verified. It's a
good thing because Django, by itself, does not verify email addresses. The
social auth providers that we use do validate them, but not Django, and
when internal auth is involved then it's only Django.
In that case, how should this address be validated? Should Postorius
consider that the login system always validates addresses and set them as
verified in Mailman? Should it ask mailman to verify the email addresses
when it encounters a user's un-verified address? This does not seem
possible in REST at the moment (unless I missed it), and should be
protected against multiple checks.
Ideas?
Aurélien
I tried the doing it the way you did and got the same result. After
checking with "dir()" I found a "commit" method. I tried running it and
it worked.
>>> dir()
['IUserManager', '__builtins__', 'a', 'abort', 'commit', 'config',
'getUtility', 'l', 'm', 'now', 'um', 'user_manager', 'x']
>>> commit
<bound method SABaseDatabase.commit of
<mailman.database.postgresql.PostgreSQLDatabase object at 0x7efbf969c9e8>>
>>> commit()
>>>
Maybe it was there because I'm using PostgreSQL but it worked for me.
On Apr 02, 2016, at 06:17 AM, Anirudh Dahiya wrote:
>I have been playing with mailman shell but upon creating objects like
>domains and addresses, and subsequestly committing them to database by
>calling transaction.commit() I am unable to see changes in the database(and
>thus on Postorius)
>The current approach I am taking towards committing transaction is first
>creating a connection object by calling config.db.engine.connect() . After
>that, I am creating a transaction object by calling connection.begin() .
>Finally after creating domain and address objects, I call
>transaction.commit(),which executes succesfully, but I am unable to see
>changes being reflected in the database.
Which database backend are you using, SQLite or PostgreSQL?
When you're checking the database, is this from a different process? How are
you checking the database? Can you give us the exact set of commands you're
using both to change things and to check things? E.g. maybe paste a console
session so we can reproduce it.
`mailman shell` exposes some globals, such as commit(), abort(), the config
object, and the mailing list `m` object if you gave the -l option. I don't
think you normally need to do the config.db.engine.connect() call or the
connection.begin() call, and I don't know whether those are create
subtransactions or otherwise interfering with your operations.
Cheers,
-Barry
Hi
I have been playing with mailman shell but upon creating objects like
domains and addresses, and subsequestly committing them to database by
calling transaction.commit() I am unable to see changes in the database(and
thus on Postorius)
The current approach I am taking towards committing transaction is first
creating a connection object by calling config.db.engine.connect() . After
that, I am creating a transaction object by calling connection.begin() .
Finally after creating domain and address objects, I call
transaction.commit(),which executes succesfully, but I am unable to see
changes being reflected in the database.
Thanks
Anirudh Dahiya
(IRC spark)