On Jan 8, 10:34 am, "Brian O'Connor" <[email protected]> wrote:
> I’m developing an application now and the time has come to start  developing
> the user accounts portion of the website.  This is my scenario
>
> I have no need for permissions / groups / administrators or an
> administration panel.
>
> Every visitor to the site MUST be a User.  This means that when I make a
> request, if I don’t have a user_id in the session, I create a User() for
> them and store it in their session.
>
> Users need to be able to login, logout, register, etc.
>
> I would like to connect it with Facebook and twitter.
>
> I would also like to explore the possibility of allowing people to use
> OpenID to create their accounts and login, but they must create a username
> on my site regardless of their login method.
>
> Should I seriously consider repose.what/who, or should I just roll my own
> middleware that just places a remote_user into the request?
>

Hey Brian,

repoze.who is only going to give you the authentication piece. It
doesn't facilitate registering etc... also, in my opinion, register
also implies password reset, so you may want to be thinking about that
too.

FWIW, I spent a good portion of December attempting to write a
"generic framework" to provide  somewhat "reusable" "components"
or :"patterns" I threw it up on bitbucket after I felt it was solid
enough that someone else might find it useful.

http://bitbucket.org/twillis/identity.model

While the apps are written in bfg, there are examples of integration
via paste/wsgi. Feel free to look it over for inspiration. But to
answer your overall question, the experiment from December pretty much
convinced me, that looking for a drop in solution for auth/
registration is somewhat hopeless in most situations. Those features
are too important and too tightly coupled to your application for
something general to work completely. I've noticed others have come to
the same conclusion.  That's not to say you have to write it all
yourself. I think repoze.who is useful for authentication in some
scenarios (authtkt implementation etc....),


> Thanks,
>
> Brian
>
> --
> Brian O'Connor
-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.


Reply via email to