Second 2008 World Wide Sprint (Feb 23)

[Mark Ramm]

I'm planing to be in Colorado on Febuary 23, and to have a local
sprint day there, acompanied by whoever wants to join in for a world
wide sprint day. I assueme that some folks will work on TG2 and
others will work on 1.1, and that still others will work on Pylons or
other related projects.

I'll add more information to the Wiki as more details are determined.

--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

[percious]

I just received this message from Jim Baker (to the
frontrangepythoneers)

>Chris,
>
>I've confirmed availability of the bivio space, so we're all set for holding
>the sprint on Feb 23. I'm really looking forward to it, especially resuming
>work on Genshi. I was recently asked about Trac on Jython, and getting
>Genshi going would be a key part of that support too.
>
>- Jim


Should we set up the sprint organization page to be like it was last
time?

I really think an emphasis on some kind of Identity solution should be
made.

-chris

[iain duncan]

On Tue, 2008-05-02 at 12:23 -0800, percious wrote:
>
> I just received this message from Jim Baker (to the
> frontrangepythoneers)
>
> >Chris,
> >
> >I've confirmed availability of the bivio space, so we're all set for holding
> >the sprint on Feb 23. I'm really looking forward to it, especially resuming
> >work on Genshi. I was recently asked about Trac on Jython, and getting
> >Genshi going would be a key part of that support too.
> >
> >- Jim
>
>
> Should we set up the sprint organization page to be like it was last
> time?
>
> I really think an emphasis on some kind of Identity solution should be
> made.

+1 on that!

Iain

[Paul Johnston]

Hi,

I really think an emphasis on some kind of Identity solution should be
made.

We've already got instructions for using AuthKit with TG2, so some auth* solution is available already. Potential next steps are:

a) Making a TG1 identity compatible layer
b) Create a wonderful, all-powerful new auth* API

Thing is, I'm not sure (a) is that important, or that we're ready to do (b) just yet.

Paul

[Lee McFadden]

On Feb 6, 2008 9:37 AM, Paul Johnston <p...@pajhome.org.uk> wrote:
>
> We've already got instructions for using AuthKit with TG2, so some auth*
> solution is available already. Potential next steps are:
>

We do? If you're talking about the page in the 2.0 RoughDocs
section[1] then I strongly disagree that we have instructions - that
page consists of some barely explained notes and doesn't actually show
how to use Authkit at all.

[1]: http://docs.turbogears.org/2.0/RoughDocs/AuthKit

> a) Making a TG1 identity compatible layer
> b) Create a wonderful, all-powerful new auth* API
>
> Thing is, I'm not sure (a) is that important, or that we're ready to do (b)
> just yet.
>

I would need to poke around with Authkit to actually have a good
opinion on this but from what I've read elsewhere Authkit is good for
authentication but annoyingly complex for authorization. Maybe a mix
and match approach would be better?

I'm going to be starting a project with TG2 soon and auth/auth will be
required so I'm hoping I'll be able to contribute to this effort.

--
Lee McFadden

blog: http://www.splee.co.uk
work: http://fireflisystems.com
skype: fireflisystems

[Kevin Horn]

My preference is for b).  Making authkit compatible with the TG Identity framework would be pretty tough, because it just won't do some things that Identity will.  Or at least, it would be pretty ugly, and probably fragile.  I was pretty impressed when I initially read about authkit, but am becoming less so, the more I find out.

I had started some work on an auth layer about a month ago, but it got stalled due to the 2.4 incompatibilities which were introduced with the switch to WebOb (though those should be fixed now).  I haven't had a chance to go back to it, as I'm pretty much slammed at least through this week.  I probably just need to start over anyway.  I'm really hoping to get some serious progress made on this during the sprint (and maybe before).

Kevin Horn

[percious]

Here is an open invite to any developers who want to come down to
Denver.

I am happy to put you up. My family is visiting Maryland for a that
weekend, so I have at least 4 beds available. I can also pick people
up at DIA if y'all can coordinate timing.

I live about 30 minutes from Boulder, 45 minutes from DIA.

I would be happy to provide food and beer as well. Part of the
weekend could even be spent in outdoor pursuits. Great hiking/
snowshoeing/climbing/Skiing in/near the Front Range. I am willing to
take Friday off work if people want to come in on thursday night and
have a "play/planning" day on Friday.

Hey, Zope had a snow sprint, why cant we?
http://www.openplans.org/projects/snow-sprint-2008/project-home


cheers.
-chris

On Feb 6, 8:36 am, "Kevin Horn" <kevin.h...@gmail.com> wrote:

[Paul Johnston]

Hi,

>>We've already got instructions for using AuthKit with TG2, so some auth*
>>solution is available already. Potential next steps are:
>>
>>
>We do? If you're talking about the page in the 2.0 RoughDocs
>section[1] then I strongly disagree that we have instructions - that
>page consists of some barely explained notes and doesn't actually show
>how to use Authkit at all.
>[1]: http://docs.turbogears.org/2.0/RoughDocs/AuthKit
>
>

The instructions are tried-and-tested, and get you going with AuthKit on
TG2. AuthKit has its own documentation that describes the API.

>I would need to poke around with Authkit to actually have a good
>opinion on this but from what I've read elsewhere Authkit is good for
>authentication but annoyingly complex for authorization. Maybe a mix
>and match approach would be better?
>
>

Yes, I'm sure there are a few gems to be picked up from all the existing
auth* systems. One thing I was thinking as well is creating a wiki page
where people can share complex permissioning models they've created.
There was some chat about these at my local PUG. The main requirement I
have for auth* actually is integrated Windows authentication.

Paul

[percious]

I think it would be valuable to have a TG2 template with authKit built-
in for identity. Not having identity is definitely a barrier to use
when things like Plone/Grok/Django do authentication out of the box.

Also, I like the @identity decorator and I wondered if there was a TG2
equivalent yet? What about identity.requires = "admin" and such in the
controllers. Is that working in TG2? This is the real meat and
potatoes of what I am talking about getting working.

-chris

[Kevin Horn]

On Feb 8, 2008 2:27 PM, percious <ch...@percious.com> wrote:

I think it would be valuable to have a TG2 template with authKit built-
in for identity.  Not having identity is definitely a barrier to use
when things like Plone/Grok/Django do authentication out of the box.

Also, I like the @identity decorator and I wondered if there was a TG2
equivalent yet? What about identity.requires = "admin" and such in the
controllers.  Is that working in TG2?  This is the real meat and
potatoes of what I am talking about getting working.

-chris

Identity is pretty much missing from TG2 at this point.  AuthKit or one of the other WSGI toolkits is pretty much the only thing available at the moment. (AFAIK)

I've restarted my identity stuff, and I hope to have something vary basic along with some clear notes by the time of the sprint, so that I (and interested others) can get this going.  I agree that identity-management is key to making life easier for the developer (which is kinda the point of TG, IMO).

Here's what I would like to see in a new identity-like package:
- be able to use it everywhere you could in TG1
- cover the traditional user/group/permission model of auth handling
- support HTTP basic/digest auth
- support form-based auth
- support OpenID (less important to me personally, but I know others really want this feature)
- support multiple methods of authentication info storage (DB, NTLM, .htaccess, LDAP, unix passwords, etc...)
- support multiple methods of authorization info storage (DB, LDAP, etc...)
- make very extensible, so users can severely customize it if they want (use setuptools!)
- have sane, covers-90%-of-use-cases default configuration

I think that covers it...good thing I'm not asking for much :)

I'm really less concerned with making the API exactly like identity, though I have no specific complaints about that API.

Kevin Horn

[Mark Ramm]

> I've restarted my identity stuff, and I hope to have something vary basic
> along with some clear notes by the time of the sprint, so that I (and
> interested others) can get this going. I agree that identity-management is
> key to making life easier for the developer (which is kinda the point of TG,
> IMO).
>
> Here's what I would like to see in a new identity-like package:
> - be able to use it everywhere you could in TG1
> - cover the traditional user/group/permission model of auth handling
> - support HTTP basic/digest auth
> - support form-based auth
> - support OpenID (less important to me personally, but I know others really
> want this feature)
> - support multiple methods of authentication info storage (DB, NTLM,
> .htaccess, LDAP, unix passwords, etc...)
> - support multiple methods of authorization info storage (DB, LDAP, etc...)
> - make very extensible, so users can severely customize it if they want (use
> setuptools!)
> - have sane, covers-90%-of-use-cases default configuration
>
> I think that covers it...good thing I'm not asking for much :)
>
> I'm really less concerned with making the API exactly like identity, though
> I have no specific complaints about that API.

Sounds good to me.

I think the @require decorator and the predicite checking syntax are good.

i would love to see user/group/permission stuff grabbed by the
identity middleware and put into the wsgi environ, so that the
decorators are just dependant on the identity key in the environ.
That will localize all of the provider customization in the
middleware, and I agree that need to be designed up front to work with
multiple backends. I also think it might be worthwhile offering an
option to cache all that information in the beaker session, so that
folks using Memcachd can avoid a database hit for users who are
already authenticated. But that's the kind of thing that we can grow
later. But I do think it totally reasonable to have identity depend
on beaker for "visit" like functionality if necessary.

--Mark Ramm

[Kevin Horn]

I've been thinking along the same lines.  Some kind of session management piece is (IMO) definitely necessary, and since beaker is already there, that's what I was planning on using.

So when the user logs in, a "user object" is created and inserted in to the WSGI environ.  The user object I had in mind looks something like this:

user.name = <username>
(or a default username that indicates noone has authenticated, like "anonymous")
user.groups = <list of groups that this person is a member of> or None
user.permissions = <list of permissions that this person has> or None

now @require can just use this, and you can also use the user object inside your controller if need be.

...or if the user object approach isn't workable for some reason, you could put the above into separate wsgi environ vars, though I like the object approach better, personally.

Perhaps even the user object could be pluggable, allowing users to create their own user objects.  Most people shouldn't need this, but I'm sure it would be useful to some.

Thoughts?

Kevin Horn

[Felix Schwarz]

Kevin Horn schrieb:

> Perhaps even the user object could be pluggable, allowing users to
> create their own user objects. Most people shouldn't need this, but I'm
> sure it would be useful to some.
>
> Thoughts?

IMHO the user object MUST be pluggable - especially if you don't have a
simple user model like identity assumes but different users which are
authenticated against different authentication sources.

Please don't assume that everything is username+password. There is more:
Sometimes clients (mostly banks) want a branch number before. Others have a
user name but require something what is essentially a second password. So
smooth 95% of the use cases (username+password) but don't make the more
complicated ones impossible.

And last but not least it should be easy to extend the auth* stuff for
things like captchas and form tokens. An implementation built into the
standard library is something (IMHO) which can be post-poned after 2.0.

fs

[Kevin Horn]

Hmmm, hadn't thought about captchas...what exactly would that require?  Just the ability to show the user some extra info, and receive some extra info from the user?  or is there something else I'm not thinking of?

Kevin Horn

[Paul Johnston]

Hi,

> Hmmm, hadn't thought about captchas...what exactly would that
> require? Just the ability to show the user some extra info, and
> receive some extra info from the user? or is there something else I'm
> not thinking of?

They're sometimes used to prevent brute force password attacks. They can
also be used to prevent a particular kind of DOS attack. So, you have
your normal login, and after three bad passwords instead of locking the
account, require a captcha for each login attempt.

I've seen this in use on a few live sites, seems to work ok. To be
honest though, most sites just have lockout on three bad passwords and
live with the denial of service risk (maybe expiring lockouts after 1
hour). I've not seen that be a problem in practice.

Paul

[Kevin Horn]

OK, so adding to my list of features...track number of failed logins!

Kevin Horn

[Kevin Horn]

I started a new thread for identity-related stuff:
http://groups.google.com/group/turbogears-trunk/browse_thread/thread/a10219f9910753b7

Kevin Horn