Web-based membership management

Web-based membership management

[Ben Schmidt]

Hi, once again!

The final two things on my wish list for now are to do with membership management. 
This is the first.

I'd like a web interface to allow membership management. I can easily write 
something in PHP to do this and have it join the other web interfaces in contrib.

However, it is a bit more involved than the other interfaces. Control files are 
easy to fiddle with as they can be changed to have permissions writable by the 
webserver. Moderation is bearable, as emails can be sent that just do the job. For 
subscription and unsubscription, though, more care is needed. Permissions can't 
just be changed, as subscription/unsubscription by email would be affected. Mail 
can't simply be sent to do the job, as confirmation requests and so on would be 
generated undesirably.

So...I'd like to propose an extension to subscription handling, where the subject 
line of mails to +subscribe or +unsubscribe can contain the commandline options of 
mlmmj-sub or mlmmj-unsub (as appropriate), excluding -L. The argument for -L would 
be implied by the address the mail was sent to, of course. Different addresses to 
the address the mail came from could easily be (un)subscribed by using the -a 
argument: in fact, it would be required to be the beginning of the subject line in 
order for the mechanism to be activated. To be secure, it would require the email 
to come from the list owner or someone listed in submod.

A web interface could easily generate such emails to do required list admin.

Perhaps for added security it could be required to be turned on with a tunable.

How does this sound?

Ben.

Re: Web-based membership management

[Franky Van Liedekerke]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On Tue, Jan 26, 2010 at 2:21 PM, Ben Schmidt
<mail_ben_schmidt@yahoo.com.au>wrote:

> Hi, once again!
>
> The final two things on my wish list for now are to do with membership
> management. This is the first.
>
> I'd like a web interface to allow membership management. I can easily write
> something in PHP to do this and have it join the other web interfaces in
> contrib.
>
> However, it is a bit more involved than the other interfaces. Control files
> are easy to fiddle with as they can be changed to have permissions writable
> by the webserver. Moderation is bearable, as emails can be sent that just do
> the job. For subscription and unsubscription, though, more care is needed.
> Permissions can't just be changed, as subscription/unsubscription by email
> would be affected. Mail can't simply be sent to do the job, as confirmation
> requests and so on would be generated undesirably.
>
> So...I'd like to propose an extension to subscription handling, where the
> subject line of mails to +subscribe or +unsubscribe can contain the
> commandline options of mlmmj-sub or mlmmj-unsub (as appropriate), excluding
> -L. The argument for -L would be implied by the address the mail was sent
> to, of course. Different addresses to the address the mail came from could
> easily be (un)subscribed by using the -a argument: in fact, it would be
> required to be the beginning of the subject line in order for the mechanism
> to be activated. To be secure, it would require the email to come from the
> list owner or someone listed in submod.
>
> A web interface could easily generate such emails to do required list
> admin.
>
> Perhaps for added security it could be required to be turned on with a
> tunable.
>
>
Hi Ben,

I like all the other stuff you proposed, but not this one :-)
From-addresses can be faked easily by script, so to just base yourself on
the sender as security mechanism is imho a no-no.
If I'm not mistaken, you don't like the other interfaces since they require
certain parts of the mail-list data to be web-writeable, correct? I'm
thinking that apache authentication/authorization is sufficient to protect
whatever part you want, and by limiting the files writeable by the webserver
to eg. just the subscribtion data, you're good to go, no?
What you're requiring is automatic mail-based list actions and to be honest,
I trust my webserver more than a from-address :-)

Franky

[-- Attachment #2: Type: text/html, Size: 2762 bytes --]

Re: Web-based membership management

[Ben Schmidt]

>> So...I'd like to propose an extension to subscription handling,
>> where the subject line of mails to +subscribe or +unsubscribe can
>> contain the commandline options of mlmmj-sub or mlmmj-unsub (as
>> appropriate), excluding -L. The argument for -L would be implied by
>> the address the mail was sent to, of course. Different addresses to
>> the address the mail came from could easily be (un)subscribed by
>> using the -a argument: in fact, it would be required to be the
>> beginning of the subject line in order for the mechanism to be
>> activated. To be secure, it would require the email to come from the
>> list owner or someone listed in submod.
>>
>> Perhaps for added security it could be required to be turned on with
>> a tunable.
>
> Hi Ben,
>
> I like all the other stuff you proposed, but not this one :-)

:-)

> From-addresses can be faked easily by script, so to just base yourself on
> the sender as security mechanism is imho a no-no.

I was leaning that way, too, but then I figured, "it's exactly as secure
as mlmmj is for moderation." But I'm wrong. Moderation has a cookie, so
it's more secure. Duh.

> If I'm not mistaken, you don't like the other interfaces since they require
> certain parts of the mail-list data to be web-writeable, correct?

No, it's more that it's technically much more difficult and probably
harder to secure. They need to be web-writeable but also writeable by
mlmmj or mail-based subscriptions won't work. A lot of fiddling with
putting users in groups and making things group writable would be
necessary, and could be dangerous, giving the web server or mlmmj access
to other things it shouldn't if not done carefully. The mlmmj
administrative overhead to get things working, particularly with the web
interfaces, is already quite high. It can do without an extra level of
complexity!

So...we need another simple, but more secure interface. I still lean
towards something using email. mlmmj is definitely connected to email,
and almost any php installation is likely to have mail available, unlike
other things such as running an executable.

Maybe simply incorporating some kind of shared secret would do the
trick: a passwd control file that both the webserver and mlmmj can read
and which must prefix the subject line. If just used for the web
interface, using a random string would work and be pretty secure. For
convenience of list admins if they want to use the feature, they can set
up a more usable password as secure (or insecure) as they desire.

Would that suffice?

Ben.