[okfn-help] Bibliographica ticket #76 OpenID login and API keys

[Graham Higgins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16 Jun 2010, at 11:04, Rufus Pollock wrote:

> Can you push your current code to your bitbucket repo so we can have a
> look prior to you/will pulling into main repo?

Okay, I will do that now, so that you can take a look at the code ---  
but do bear in mind that it was a very quick sketch and my primary  
objective was to demonstrate that the combo offered a short cut to  
(what I thought might be) an acceptable user-managed OpenID sign-in  
facility. I've started on the three-way merge entailed by losing the  
elixir dependency, so the accounts controller is no longer functioning.

> I'd like to avoid using Elixir if that were possible and just use
> plain old sqlalchemy.
> [ ... ]
> This sounds good: one less dependency at small cost is something I  
> like :)

/real/ vanilla SQLA or declarativeBase?

Losing the extra level of abstraction provided by elixir will raise  
the technical bar a little for instance administrators who might want  
to extend the identity model for their own purposes. IMO, elixir  
models do provide very direct and economical expressions that are  
easier to comprehend than even SQLA's declarativeBase expressions and,  
for my money, elixir is well worth one other dependency amongst several.

> what are the pros/cons or using repoze.who / repoze.who.openid for
> basic identification

Additional dependencies would be acquired and, as you point out, it'd  
involve more work. I can't see that there'd be much of a gain in terms  
of enhanced functionality over what's already provided, unless there  
are requirements for, say, a wider range of back-end auth support  
(such as LDAP, etc.). Repoze.who brings a lot of flexibility but in  
this instance (as far as I am aware), that's not a key requirement -  
the core functionality is already well covered. One detail: my SQLA  
identity model uses bcrypt for handling password "crypto", it comes  
strongly recommended but I think I'll need to strip it out as it  
creates an additional dependency.

> We're not using RDF for storing auth info here so I assume this isn't
> so relevant right? (But maybe for future migration?)

Yes, I included the mention in case that route was seen as highly  
attractive for other reasons. I plan to do a bit of experimenting  
there, at another time.

> On form generation front we should probably have a discussion sooner
> rather than later :) about what libs we use. For other projects we've
> used FormAlchemy (and previously formencode) but I'm really open to
> suggestions here as none of these options has really worked perfectly

It's never going to be a perfect fit, UI that works is time-consuming  
to produce. The accounts controller uses mako templates, the web forms  
UI uses toscawidgets middleware and tw.forms for rendering, with  
formencode for validation and re-presentation on error. I've found tw/ 
forms to be a good solution for my purposes - I particularly  
appreciate the way i18n works well. Given the focus on moving forward,  
Formalchemy could well be an economical additional means of exposing a  
user prefs web i/f - which users will probably expect to be available  
as a consequence of being able to register and login. A means of  
managing OpenID identities and the basic registration details is  
probably the minimum.


- --
Cheers,

Graham

http://www.linkedin.com/in/ghiggins





-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkwZNSUACgkQOsmLt1NhivyRiACdG1nOtMh66dumoBeVCNIL73lq
uWcAn0wqneQlIn/BI1HXkqkX0jn2V+KoiQCVAgUBTBk1JVnrWVZ7aXD1AQL4jAP/
Z1A1zzBPTx954j7JoV8SP4r3CLNszxLiYPFa/TV3NhtQfT+V2Uq4yYmmvra7UnyM
OLbY4PzWFY2DabRpLqPEkqiihpJ1GZVhfax4pL9TA1k+9SvF8PD70pUDEtss0zPw
b3YccVyDFtRhKzwql5RIoA7NXf5i8uyBdG54HNZAEsU=
=809B
-----END PGP SIGNATURE-----