[Systers-dev] Fwd: [Mailman-Users] [Mailman-Developers] openID enabled mailman

Sarah Mei sarahmei at gmail.com
Mon Jul 6 13:35:02 PDT 2009


I'm reading through the wiki, and I'm a bit confused about the ORM project.

It sounds like the Systers mailman data is already in postgres (not in
pickle files). The ORM project is abstracting a layer between mailman
and postgres (via storm) so that there isn't so much custom code in
mailman.

All pretty straightforward. Where I get confused is when we're talking
about writing a MembershipAdaptor, which can be swapped out in mailman
for the standard one, for use in the OpenID proejct. Will that use the
generated ORM objects, or is it part of the ORM project? If membership
data is already in postgres, does the Systers mailman codebase already
have a nonstandard MembershipAdaptor?

And on a more or less separate note, is the code available anywhere? I
suspect most of these questions could be answered if I spent an hour
looking at the customized code.

BTW, no one has taken the username systers on Github - you all should
register it. :)

Sarah

On Mon, Jun 15, 2009 at 12:12 PM, Jennifer Redman<jenred at gmail.com> wrote:
>
>
> On Mon, Jun 15, 2009 at 12:08 AM, Malveeka Tewari <malveeka at gmail.com>
> wrote:
>>
>> Hi Sarah
>>
>> Thanks for your input.
>> I am presently working on the third step - patching up mailman to support
>> OpenID as a relying party.
>> This is an interesting page that lays a road map as to how to implement
>> OpenID for a website that has user accounts.
>> http://www.plaxo.com/api/openid_recipe
>
> Once caveat is to remember to think in terms of scalability.  We are using
> mailman uid's and passwords because our 2500+ membership base already has
> those uids and pw and it would be much easier to grant members access to
> other applications using their existing accounts.
> I really think that we are missing a step that comes before working
> primarily on OpenId or Cookies, or LDAP and that is converting our existing
> membership base that is stored in Mailman to be stored in an object that is
> (I think this is what Sarah is getting at as well as those who responded to
> your posts on the mailing lists)
> 1) More secure
> 2) Stored and accessed in a way that will be accessible to multiple
> applications (including mailman) (preferably in Postgres), (and has the
> potential to support a gui so Systers are able to change their UID/Pasword
> options - future project)
> Think in terms of a Systers membership management tool.  Additionally,
> mailman is going to change and eventually become MM3 which is a complete
> rewrite.  We need to make sure that the work we do now is not going to
> necessitate a complete rewrite every time an upgrade comes along or we'd
> like to make a new application available.  I don't think that just patching
> up mailman 2.x is really a scalable solution.
> Malveeka, I think you need to have a least a conversation with Andy and
> Kanika Vats (and Sarah too if you are interested) about the ORM project and
> a possibility of created some sort of sql membership type module that can be
> used with multiple authentication options (including Mailman)
> Jen
>
>


More information about the Systers-dev mailing list