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

[Rufus Pollock]

On 16 June 2010 10:20, Graham Higgins <gjh at bel-epa.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Floating a kite for addressing most of #76 (adding OpenID login and API keys) and showing a functioning candidate solution.]

This looks great. Couple of comments below.

> <http://knowledgeforge.net/pdw/trac/ticket/76>

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

> Flickr set of screenshots showing the web interface:
> http://www.flickr.com/photos/46197271@N00/sets/72157624286088556/

[...]

> Shabti
> ======
> Some other alternative approaches to auth'n'auth are available and I've explored a couple in Shabti, which I'll include here purely to illustrate that a lot of the preliminary spadework has already been done:
>
> + the Kai identity model expressed in Elixir (1) and the accounts controller (and accompanying OpenID consumer controller) decanted into a Shabti template:

I'd like to avoid using Elixir if that were possible and just use
plain old sqlalchemy.

Also, not that there is anything at all wrong with this approach :),
but what are the pros/cons or using repoze.who / repoze.who.openid for
basic identification (I'm aware that doesn't do work of plugging into
backend user model -- that we'd obviously still need to code ...).

> http://bitbucket.org/gjhiggins/shabti/src/f4ae951fb588/shabti/templates/authplus/+package+/controllers/accounts.py_tmpl
>
> + The old tesla-pylons-elixir elixir/SQLA identity model re-expressed using Phillip Cooper's "RDFAlchemy" (an RDF ORM for Python) --- this should be fairly straightforward to re-express in ORDF:
>
> http://bitbucket.org/gjhiggins/shabti/src/f4ae951fb588/shabti/templates/auth_rdfalchemy/+package+/model/rdfmodel.py_tmpl

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

> Expanding or contracting the range of attributes of the identity model is straightforward in any of the approaches and I don't anticipate any difficulties in that direction.
>
> (1) TBH, it's all the same model (by design) and a vanilla SQLA version of the identity model is defined in one of the other Shabti templates. So if an identity model expressed in vanilla SQLA is preferable to one expressed in elixir (perhaps a sensible approach as it's one less dependency to worry about) then it's pretty much just a copy'n'paste job.

This sounds good: one less dependency at small cost is something I like :)

> [ some time later ... ]

[...]

> It all adds dependencies (SQLAlchemy, elixir, Babel, pytz, python-openid, toscawidgets and tw.forms) but all are pure Python. With some work, a few of these additional dependencies could be made to go away but this is pretty much exactly the kind of job that they were designed to perform. IMHO the more compelling argument might be the amount of ground covered.

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
...

> The only potentially knotty problem is the "system of owners and permissions on RDF graphs", the SQL store will need to keep in synch with the various comings and goings of user-generated graphs in the RDF store.

Important question Graham.

> I wonder if signed graphs have any relevance here?
>
> http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf
> http://semedia.deit.univpm.it/submissions/www2005/WWW2005_signignRDF.pdf

Sounds like the start of a separate thread!

Rufus
--
Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/