Re: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman
On Nov 05, 2012, at 09:18 PM, Florian Fuchs wrote: Of course it would be nice if a public API wouldn't require Django. But we already have authorization functionality for all kinds of roles in Postorius. And to add a JSON API shouldn't be so hard. I think it's great for Postorius to provide an authenticated API. The beauty of our approach is that if someone wants to start a separate project for a Django-less authenticated API, there's nothing stopping them. In fact, I played around with this a little over the weekend. I didn't want to change too much of the existing authorization system, only slightly enhance it to provide a simple way for non-browser clients to log into Postorius with existing user credentials. What I came up with is a simple view decorator that checks for an HTTP Basic Auth header if the current user isn't logged in and uses these credentials to start a new Django session. Clients that can handle session cookies can use that in all concurrent requests (which makes it a little faster). Clients that don't support cookies can just send the auth header again with the next call. Does Django support OAuth? If so, I think that will be better in the long run than Basic AUTH, though I think both must be used over HTTPS for security reasons. I had some very interesting discussions with one of the original OAuth authors at UDS-R, and while v1 has its issues, v2 seems to be even worse. Yet, it seems like the best option out there if users want to use applications without having to provide their login credentials directly. Fortunately, there are several Python libraries that support at least OAuth v1, although the library I'm currently liking is liboauth, which supports both v1 (client) and the draft for v2. As I understand it, only Facebook's API requires v2; most services support v1 and it's not that hard to support on both the client and server. Theres also an API resource that returns a json string with all mailing lists (very similar, but not identical to the one the core API returns). If anyone's interested: I added a small proof of concept for a command line client to a private branch on launchpad. It's far from mature, just to see if the idea works... https://code.launchpad.net/~flo-fuchs/+junk/mmremote. (Please make sure to use the latest revision of Postorius). Another thought: We will add some convenience AJAX functionality to the Postorius UI. For this alone it's worth having a number of JSON resources available. In other words: Postorius would be the first client to use its own API :-) I *love* eating my own dogfood. :) -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman
Hi, On 10/26/2012 08:15 PM, Barry Warsaw wrote: One thing we need though is an authenticating proxy for the REST API so that non-localhost users can script their own changes to lists they own or are members of. We can't expose the admin REST API to non-localhost and I really don't want to have to add the authentication layer to the default REST API (at least not right now). It's possible that such an authenticating layer could be implemented as part of Postorius, since I think Django supports REST also, and you'll *have* to be authenticated to interact with Postorius. OTOH, it would be nice if that could be provided without requiring Django. Of course it would be nice if a public API wouldn't require Django. But we already have authorization functionality for all kinds of roles in Postorius. And to add a JSON API shouldn't be so hard. In fact, I played around with this a little over the weekend. I didn't want to change too much of the existing authorization system, only slightly enhance it to provide a simple way for non-browser clients to log into Postorius with existing user credentials. What I came up with is a simple view decorator that checks for an HTTP Basic Auth header if the current user isn't logged in and uses these credentials to start a new Django session. Clients that can handle session cookies can use that in all concurrent requests (which makes it a little faster). Clients that don't support cookies can just send the auth header again with the next call. Theres also an API resource that returns a json string with all mailing lists (very similar, but not identical to the one the core API returns). If anyone's interested: I added a small proof of concept for a command line client to a private branch on launchpad. It's far from mature, just to see if the idea works... https://code.launchpad.net/~flo-fuchs/+junk/mmremote. (Please make sure to use the latest revision of Postorius). Another thought: We will add some convenience AJAX functionality to the Postorius UI. For this alone it's worth having a number of JSON resources available. In other words: Postorius would be the first client to use its own API :-) Cheers Florian Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind.de Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman
On 12-10-26 12:29 AM, Patrick Ben Koetter wrote: first of all: I don't consider listadmin a contradiction to postorious. Me neither, don't worry, but it's always good to learn from the way other people like to use a system. That doesn't mean we need to do all of this too! in this way! so much as huh, I never thought about having an interface which showed $foo... Terri ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman
Terri, Am 24.10.2012 08:27, schrieb Terri Oda: Since I now treat every gathering of hackers as an excuse to get people to tell me things about Mailman, I was chatting with folk at the GSoC mentor summit and my friend V was telling me that she really likes Listadmin as a nicer interface to Mailman: http://freecode.com/projects/listadmin Seems like something I might have to look at and learn some lessons from before we're done with postorius dev. first of all: I don't consider listadmin a contradiction to postorious. To me listadmin is simply another user interface to mailman for another user group - those that like to run (automated) commands from command line or prefer to work on command line (like I do). One of the great improvements of MM3 over previous versions is its REST interface. IIRC it was Pycon in Chicago when Barry, Florian and I discussed about the possibilities that come along with the REST interface. We came up with ideas like use a template to create and setup a mailinglist from command line, do a remote backup of list settings and subscriptions, include MM3 management in some sort of account provisioning. It's been a while since Pycon in Chicago and we might add smartphone app to deal with post requests or similar things one might want to do from an app. My favourite still is a command line interface to MM3 which I can run as a local REST client from wherever I am at the moment. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich attachment: p.vcf___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Listadmin and other alternate interfaces for Mailman
On Oct 26, 2012, at 08:29 AM, Patrick Ben Koetter wrote: first of all: I don't consider listadmin a contradiction to postorious. To me listadmin is simply another user interface to mailman for another user group - those that like to run (automated) commands from command line or prefer to work on command line (like I do). One of the great improvements of MM3 over previous versions is its REST interface. IIRC it was Pycon in Chicago when Barry, Florian and I discussed about the possibilities that come along with the REST interface. We came up with ideas like use a template to create and setup a mailinglist from command line, do a remote backup of list settings and subscriptions, include MM3 management in some sort of account provisioning. It's been a while since Pycon in Chicago and we might add smartphone app to deal with post requests or similar things one might want to do from an app. My favourite still is a command line interface to MM3 which I can run as a local REST client from wherever I am at the moment. Indeed, I agree with all of this. One thing we need though is an authenticating proxy for the REST API so that non-localhost users can script their own changes to lists they own or are members of. We can't expose the admin REST API to non-localhost and I really don't want to have to add the authentication layer to the default REST API (at least not right now). It's possible that such an authenticating layer could be implemented as part of Postorius, since I think Django supports REST also, and you'll *have* to be authenticated to interact with Postorius. OTOH, it would be nice if that could be provided without requiring Django. Cheers, -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
