Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)
> On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter wrote: > > I believe you have been asked very politely not to continue this > > thread yesterday and give way for more pressing topics such as > > GSoC. Can you please do so? This is in rather bad taste. Richard and I have been actively involved in mentoring the GSoC students, and we care about them. Please respect that, at least to the extent of reading the messages we write about the project. Richard Wackerbarth writes: > I consider that [a priori ruling out submitted proposals] is > totally inappropriate. I won't go so far as to say "totally" inappropriate. We do have to get some work done, and if the consensus is that strict adherence to the letter of Terri's post is the best way to move along ... I'll deal with it. I hope we can find a compromise, though. Steve ___ 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] About authentication (was Re: Architecture for extra profile info)
Terri, For Systers, is it better to try to access Postorius through its REST API or by directly including it as a django app? In particular, using Django 1.5 and the custom user module feature that it provides along with the scheme that I outlined earlier provides an easy path to developing and integrating features such as the essays into the user profile. Basically, we share a common User model. Someone can start by using the standard django.contrib model and ignore the Postorius specific parts. I am willing to implement the pieces (I estimate needing only a day or two if I do a simple version), but I also think that it would be an appropriate task for one of the students. Richard On Apr 30, 2013, at 10:31 AM, Terri Oda wrote: > On 13-04-29 11:28 PM, Stephen J. Turnbull wrote: >> Actually, there aren't any students explicitly discussing extra profile >> information in their proposals. They talk airily about "extended REST >> API" or similarly generic terms. None talk about storage or >> representation of profile information. (OK, it was 3am, my memory is >> fallible. I don't remember any, though.) >> > > Oh! I think I understand some of the confusion now. I thought I'd said at > the beginning why I was starting this thread at all, which is primarily > because Systers has a student project that needs extra profile info. There > are also a collection of students with minor features that would use the data > store that they've used to pad out projects that might otherwise be too short > (For example, see some of the ideas Peter Markou mentioned in his recent > post). But now that you mention it, I've been talking to a lot of folk on > IRC and they often don't tell me if they're applying with Mailman or Systers, > so maybe there's more of them with Systers than with Mailman? > > > For those not familiar, Systers runs a heavily modified version of Mailman > 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman > Suite (whenever that's going to be), but they've got a few features that > they'll need to either have integrated to core Mailman or maintained as > branches. This year, they've got a project set up to port one of them to > Mailman 3/Postorius as part of preparing them for that. > > The specific feature they're hoping to add this year stores essays that > people write when they subscribe. It's currently done with a database > grafted on to Mailman 2.1 that was being used for another extended feature, > but obviously if we're going to mentor such a project for Mailman 3, we'd > like to use something at least approximating a real data store design. The > problem is that the Systers mentors are mostly used to systers-mailman, based > on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide > a student through a halfway reasonable design, so I asked here in order to > help them out so that their student could start on the essays (likely to be > the easier part of her project) right at the beginning of the GSoC period. > If we can't come to a moderate consensus on that design, I should be telling > the Systers folk that this project won't be able to run this year, but I > honestly figured we'd have a simple design after a couple of posts... I > wasn't counting on aut hentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project. > > So yeah, totally cool to be thinking about the more advanced projects in > general, but I started this thread due to a specific need for a "good enough > approximation for this Mailman suite release" version of the extra data > store, and I still need a consensus on that that's either implemented or > simple enough for a student to do in the first week of GSoC. I think we're > pretty close to that point, but I'm not sure it's yet described in a way that > we can hand it off safely to a student and get a REST API that actually > meaningfully matches the discussion within a couple of days. Probably we > need an actual set of doctests for the student to work against next and then > we'll be there. > > Incidentally, I've been trying to get the students interested in this > particular Systers project to come to this mailing list and join in the > discussion, but it's become *very* intimidating to take part in this thread, > which is the other reason I need folk to take a step back. > > 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] About authentication (was Re: Architecture for extra profile info)
On 13-04-29 11:28 PM, Stephen J. Turnbull wrote: Actually, there aren't any students explicitly discussing extra profile information in their proposals. They talk airily about "extended REST API" or similarly generic terms. None talk about storage or representation of profile information. (OK, it was 3am, my memory is fallible. I don't remember any, though.) Oh! I think I understand some of the confusion now. I thought I'd said at the beginning why I was starting this thread at all, which is primarily because Systers has a student project that needs extra profile info. There are also a collection of students with minor features that would use the data store that they've used to pad out projects that might otherwise be too short (For example, see some of the ideas Peter Markou mentioned in his recent post). But now that you mention it, I've been talking to a lot of folk on IRC and they often don't tell me if they're applying with Mailman or Systers, so maybe there's more of them with Systers than with Mailman? For those not familiar, Systers runs a heavily modified version of Mailman 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman Suite (whenever that's going to be), but they've got a few features that they'll need to either have integrated to core Mailman or maintained as branches. This year, they've got a project set up to port one of them to Mailman 3/Postorius as part of preparing them for that. The specific feature they're hoping to add this year stores essays that people write when they subscribe. It's currently done with a database grafted on to Mailman 2.1 that was being used for another extended feature, but obviously if we're going to mentor such a project for Mailman 3, we'd like to use something at least approximating a real data store design. The problem is that the Systers mentors are mostly used to systers-mailman, based on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide a student through a halfway reasonable design, so I asked here in order to help them out so that their student could start on the essays (likely to be the easier part of her project) right at the beginning of the GSoC period. If we can't come to a moderate consensus on that design, I should be telling the Systers folk that this project won't be able to run this year, but I honestly figured we'd have a simple design after a couple of posts... I wasn't counting on authentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project. So yeah, totally cool to be thinking about the more advanced projects in general, but I started this thread due to a specific need for a "good enough approximation for this Mailman suite release" version of the extra data store, and I still need a consensus on that that's either implemented or simple enough for a student to do in the first week of GSoC. I think we're pretty close to that point, but I'm not sure it's yet described in a way that we can hand it off safely to a student and get a REST API that actually meaningfully matches the discussion within a couple of days. Probably we need an actual set of doctests for the student to work against next and then we'll be there. Incidentally, I've been trying to get the students interested in this particular Systers project to come to this mailing list and join in the discussion, but it's become *very* intimidating to take part in this thread, which is the other reason I need folk to take a step back. 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] About authentication (was Re: Architecture for extra profile info)
Patrick, This IS about GSoC. If we accept Terri's position, as stated and without question, then we are, de facto, eliminating some of the proposals based only on subject matter. The students making these proposals are doing so in good faith, and often based on "ideas" provided by our organization. I consider that doing so is totally inappropriate. As I state, we need to maintain a structure whereby each of the proposed projects can proceed without being blocked by another project, but done in such a manner that they can be integrated into the whole as they develop into functioning code. Richard On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter wrote: > Richard, > > * Richard Wackerbarth : >> Again, we agree. (Something must be wrong :) ) I think that it is important >> that "we" (the senior developers and mentors) assure that we maintain a >> structure whereby each of the student proposals can proceed at the same time. > > I believe you have been asked very politely not to continue this thread > yesterday and give way for more pressing topics such as GSoC. Can you please > do so? > > 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: Florian Kirstein > > ___ > 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/rkw%40dataplex.net > > 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] About authentication (was Re: Architecture for extra profile info)
Richard, * Richard Wackerbarth : > Again, we agree. (Something must be wrong :) ) I think that it is important > that "we" (the senior developers and mentors) assure that we maintain a > structure whereby each of the student proposals can proceed at the same time. I believe you have been asked very politely not to continue this thread yesterday and give way for more pressing topics such as GSoC. Can you please do so? 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: Florian Kirstein ___ 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] About authentication (was Re: Architecture for extra profile info)
Steve, Again, we agree. (Something must be wrong :) ) I think that it is important that "we" (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time. Thus, for example, someone working on the User interface can do so without requiring the "secure" mail features. At the same time, we provide a place (Eg. the Credentials store) that can be used to hold public keys associated with individual subscribers. Now I will admit that I haven't thought about the criteria associated with permitting someone to add a public key-->user association. But, within whatever policy is needed, we have a method to handle the storage and the framework within which the system can "GetUserByCredential()", etc. Richard On Apr 30, 2013, at 12:28 AM, Stephen J. Turnbull wrote: > Terri Oda writes: > >> 1. I would like to remind/tell you all that FOR THIS RELEASE, we will >> ONLY be supporting Mozilla Persona and passwords as authentication >> methods. > >> 3. While I agree that thinking about these things in advance is useful, >> I think this discussion is starting to crowd out discussions of >> time-sensitive things like students' GSoC applications and >> architectural choices that directly impact how they write said >> applications. > > Hold on! Who's "we" and what is being released? There are at least 3 > more or less separate projects here (Mailman core, Postorius, and > HyperKitty). For login of the webapps Postorius and HyperKitty, I > certainly agree that aiming releasing them simultaneously with core > 3.0, focusing on a particular authn mechanism (and given work done at > the sprints, it should be Persona) is appropriate. > > But Mailman 3.0 is *not* the only item on the agenda here. We have a > pile of GSoC students who want to implement various forms of authn for > Mailman core functionality (secure lists) and some REST API (not clear > to me which subproject these adhere to, the core Mailman REST API or a > new one to be provided by Postorius). AFAICT, *Persona is not > appropriate* for these use cases, as it implies interactive use of a > full-featured web browser. > > Are you saying that (despite our ideas page) these proposals are a > priori nearly unacceptable? It's also rather late in the process to > change the rules on the students: if experience is any guide, Melange > availability is going to start deteriorating soon. > >> So... can we please backburner parts of this discussion until after >> GSoC so that we don't make it impossible for anyone to start on any >> project involving extra profile info? I don't want to bog down a >> student with the need to make this choice and work with these >> decisions at this stage. > > Actually, there aren't any students explicitly discussing extra profile > information in their proposals. They talk airily about "extended REST > API" or similarly generic terms. None talk about storage or > representation of profile information. (OK, it was 3am, my memory is > fallible. I don't remember any, though.) > > >> For the purposes of GSoC this summer: >> >> Authentication for the purposes of the extra profile info data store >> will be provided by either Persona through the web interface or >> passwords. > > OK. > >> Yes, even internally for the REST interface: passwords+localhost >> are good enough for Mailman Core right now, so it's good enough for >> anything else we do short-term. > > That's going to strongly bias decision-making against at least one > REST API proposal, which was made in good faith. > > It also formally seems to rule out the secure lists proposal, which > obviously depends on an off-line non-localhost authn protocol (based > on OpenPGP or S/MIME). Is that your intention? > > Regards, ___ 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] About authentication (was Re: Architecture for extra profile info)
On 13-04-29 3:25 PM, Richard Wackerbarth wrote: I'll go further than that and suggest, for the purpose of GSoC: [snip details] These are good if you're going to do the implementation. If you're not, I'm happy to leave some of these details up to the person who actually writes the code. 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] About authentication (was Re: Architecture for extra profile info)
On Apr 29, 2013, at 3:06 PM, Terri Oda wrote: > 1. I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be > supporting Mozilla Persona and passwords as authentication methods. This is > not up for discussion at this time; it's a choice we've made to in order to > help move the release forwards. That doesn't bother me as long as we recognize that the list of acceptable methods be extensible. In other words, adding a new method would require only the addition of the necessary handlers, forms, etc. and NOT require the re-engineering of the code that handles BrowserID or username/password. > 2. As such, any discussion of enterprise use of google or twitter or what > have you is pretty much academic. I am satisfied if our authentication plan > for methods other than Persona and passwords is "And then the magical python > gnomes associate an external account with an internal mailman account!" (I'm > not being entirely facetious here; libraries such as django-social-auth are > likely to make this sufficiently trivial that it might as well be gnomes.) Agreed. > Authentication for the purposes of the extra profile info data store will be > provided by either Persona through the web interface or passwords. Yes, even > internally for the REST interface: passwords+localhost are good enough for > Mailman Core right now, so it's good enough for anything else we do > short-term. I'll go further than that and suggest, for the purpose of GSoC: 1) The USER module will be implemented as a Django 1.5 app. 2) In addition to a custom user model (https://docs.djangoproject.com/en/dev/topics/auth/customizing/#auth-custom-user), it will provide a Credential verification service. The service will store the associations between users and the parameters used to identify them -- protocol, identifier, confirmation. If the credentials match, the service will return a user_identifier which will be used to access additional information about the user. 3) The user_identifier will be of a form chosen by the USER module. Other modules (such as MM-core) may associate alternate identifiers (in their namespace) and set or retrieve them. When installed as a part of a MM system, at the installer's discretion, additional user profile information may also be added. 4) Both the User information and the Credential service will be exposed on a RESTful interface. 5) This Django app may be installed as a part of a Postorius interface or run as a standalone service. In the future alternate implementations might be considered, but this will do for now. It also has the advantage that multiple students can work on things affecting the user record without the other student's work becoming a stopping point to their progress. Then, as they get them working, they can be merged into the postorius system. ___ 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
