Struggling with Authkit Authentication
daniel
within a Pylons website project. I went through the Authkit
documentation and followed the Pylons book recommandations (chapter
18).
What I would wish setting up is the following functionality:
1- Have a Sign In authentication link on all the website pages
2- Launch the website styled Sign In Form from the Sign In link
3- Fill in the website styled Sign In form and submit it
4- In case of Sign In success REDIRECT TO THE STARTING URL (the one
from where the sign in url has been launched; obviously I'll make the
template able to show the looged in status)
5- In case of Sign In failure, show a customized 401 error document
By following the documentation and setting "authkit.setup.method =
form, cookie", I could go through the first three points. I'm
struggling to have functionality in point 4 satisfied.
Any help or recommandation is really much welcome.
This is the config I'm using:
authkit.setup.enable = true
authkit.setup.method = form, cookie
authkit.form.authenticate.user.type =
authkit.users.sqlalchemy_driver:UsersFromDatabase
authkit.form.authenticate.user.data = mysite.model
authkit.cookie.secret = mysecret
authkit.cookie.signoutpath = /signout
authkit.form.template.obj = mysite.lib.auth:render_signin
authkit.cookie.params.expires = 1800
authkit.cookie.enforce = true
authkit.cookie.includeip = true
Thank you in advance
Daniel
Raoul Snyman
> I'm trying getting familiar with Authkit Authentication system used
> within a Pylons website project. I went through the Authkit
> documentation and followed the Pylons book recommandations (chapter
> 18).
http://www.letsyouandhimfight.com/2009/10/28/pylons-opinion-dont-use-authkit/
(Disclaimer: That's not my blog)
--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)
daniel
It could be that for future implementation I'll try coding a custom
auth ..
but for the time being I would really wish getting the authkit working
as I need (actually here we are still talking about basic
authentication needs)
Anyone happy with authkit would wish sharing some recommandations ?
Thank you in advance
Daniel
>
> > I'm trying getting familiar with Authkit Authentication system used
> > within a Pylons website project. I went through the Authkit
> > documentation and followed the Pylons book recommandations (chapter
> > 18).
>
> (Disclaimer: That's not my blog)
>
> --
> Raoul Snyman
> B.Tech Information Technology (Software Engineering)
Raoul Snyman
> but for the time being I would really wish getting the authkit working
> as I need (actually here we are still talking about basic
> authentication needs)
For my own applications, I rolled my own, as AuthKit just didn't fit the bill.
At work, for simple authentication, we rolled our own, and for large
sytems that require authorisation, we use repoze.who and repoze.what.
--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Graham Higgins
Hash: SHA1
On 3 Jun 2010, at 08:25, daniel wrote:
> but for the time being I would really wish getting the authkit working
> as I need (actually here we are still talking about basic
> authentication needs)
> 4- In case of Sign In success REDIRECT TO THE STARTING URL (the one
> from where the sign in url has been launched; obviously I'll make the
> template able to show the looged in status)
You might get what you need from the AuthKit Cookbook:, c.f.
http://wiki.pylonshq.com/display/authkitcookbook/Forward
> 5- In case of Sign In failure, show a customized 401 error document
ICBW, but I suspect that you'll find this one rather challenging.
authkit-as-middleware intercepts /all/ outgoing 401s - they trigger
authkit to present the sign-in page instead - the user never see the
401, just the sign-in page - which, in the case of failed authn, is re-
presented by Authkit itself, the incoming login data is handled by
Authkit before your app is even called. Hard to see how you're going
to sneak a decorated 401 past AuthKit without the response being
swapped out for a redirect to the sign-in URL. That switch is the
designed behaviour, so (AIUI) you've essentially created a spec for a
non-standard approach --- which will probably involve you in modifying
the AuthKit code unless you can relax your spec to allow re-
presentation of the sign-in page.
If you need the same functionality in a non-middleware approach, you
might get some ideas from the Shabti basic auth'n'auth project
template ]1] which will tick your boxes from #1-#4 and which will give
you an opportunity to implement #5 in your app.
Alternatively, repoze.who maintains a count of login attempts, which
you can exploit to present a suitably decorated sign-in page when
count>0, if that will satisfy your requirements.
[1] http://bel-epa.com/shabtidocs/shabti_templates/shabti_auth.html
[2] http://wiki.pylonshq.com/display/pylonscookbook/Authentication+and+Authorization+with+%60repoze.who%60
HTH
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkwHahcACgkQOsmLt1NhivyFhgCfb4UWrFTVadBqzCpNv9F1Fk6b
fFgAoMNpLF5icJyQBs+r5ck1SX67d31uiQCVAgUBTAdqF1nrWVZ7aXD1AQLf4gP8
C39uDVZxiYS7mld7Haezq25wo6ZJpPAIGqdNySnV1UqRP1nWdACXsNUND4poAWGs
TfhsXIYwQi9wnQJ6PpI59P9oXtcdYrT5uytT22qdPfWYbyYWenIp+aKxFxByb7YF
TaymhufJRdjkYbPZZPa9Q46tIuRs5zOdQLdU7kkvHDU=
=mQhu
-----END PGP SIGNATURE-----
daniel
at the shabti_auth I wasn't aware of.
Actually I realized those difficulties related to spec points 4 and 5
under authkit usage
For the time being and for this project I had to find out
compromizes:
- I could manage redirecting to referrer url on successful
authentication by tracking it with cookies
- As you explained no way for a customized 401 error document. I
compromized the spec by managing to show a session flash message on
the authkit redirected signin page. This is enough for showing the
user the entered data were wrong. The session flash message is
activated into render_signin() if request.params multidict is not
empty ( I use this config :
authkit.form.template.obj=mysite.lib.auth:render_signin)
Cheers
Daniel
Graham Higgins
Hash: SHA1
On 3 Jun 2010, at 17:47, daniel wrote:
> Thank you Graham for these precious inputs.
Good, I'm glad it was of some use.
On a slightly more general note:
I would recommend that all developers who are currently using AuthKit
(or who plan to do so) should read and inwardly digest the statements
on this page:
<http://jimmyg.org/work/code/index.html>
in which James lists those of his Python modules that are currently
maintained and those which he is personally moving away from:
1. "Currently maintained Python modules:" (the list does not include
authkit)
2. "Phasing out of my own projects:
* Pylons - I'm using Flows ... instead.
* FormBuild 1 and 2 - use FormBuild 3 instead.
* AuthKit - I'm using [... other packages ... ] instead."
(note that the URL for AuthKit in the page is incorrect, the domain is
authkit.org)
AuthKit sources and the development repository is here:
<https://hg.3aims.com/public/AuthKit/summary>
(last change Fri, 27 Nov 2009 20:43:41 +0000)
Developers should also take careful note that the last release of
AuthKit (0.4.5) is pinned to sub-0.6 versions of SQLAlchemy:
"SQLAlchemy>=0.5.0,<=0.5.99"
My personal conclusion is that in theory and in practice, AuthKit is
no longer maintained (and reflecting that, I have removed the authkit
template from Shabti).
James is quite explicit about the caveats --- "you should use my code
at your own risk because the probability I'll move on to something
different fairly quickly is rather large".
Inevitably, there comes a point at which the best advice to provide to
enquirers is: "you should abandon this approach unless you are
prepared to maintain the package yourself"
On the #pylons IRC channel, questions on the suitability of AuthKit as
an auth'n'auth solution for Pylons apps typically meet emphatically
strong deprecations from experienced and mature Pylons developers.
I may have done you no favours at all by seeming to encourage you to
continue down what is very likely to be a developmental dead-end.
I fully appreciate the project constraints that bind you but I felt I
should make the above as clear as I could, just to avoid any
misconceptions.
HTH
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkwIz4AACgkQOsmLt1NhivzCqgCgy9OJbZwUn/RRWUsxbocpMykb
XGYAnjoFil4scJWUz0wkzeH0P7KEv9WTiQCVAgUBTAjPgFnrWVZ7aXD1AQKgNAQA
4dEc7adXzyz/ONi0qKyLFgYxNfo7l1oa6/AGC6Ff4dOOL6e2XQ2dauftfQTY+mli
Uel3H/YpvK9PDEdkODudZ+GT6O/OepgLnAS0y/41y6VX3VPeS23A7QgQlY9TVSL9
TIRcvzY8pZkOO5bqA5cCCGDcmleDtGAYBHhxlVOExCg=
=luzi
-----END PGP SIGNATURE-----
daniel
I really appreciate your comments
Actually they are scaring largely much behind authkit
After a look at <http://jimmyg.org/work/code/index.html> , where
Pylons appears in the list of phased out projects (by the co-founder,
although it seems there is still a community maintaining the project)
and where I can read the following :
« Phasing out of my own projects: Pylons - I'm using Flows (which I
absolutely love) instead. It corrects all the problems with WSGI and
Pylons which I discovered when writing the Pylons Book and is a
complete re-write of the whole codebase and core dependencies from
scratch, with complete conceptual integrity and with a far more
modular architecture than even Pylons »,
my questions are :
1. Is still wise starting new long term projects based on Pylons ?
2. How strong and motivated remains the Pylons development community ?
3. Which are, if any, the long term python web frameworks to
eventually consider as alternative to pylons ? (should I re-evaluate
django , which I don't like technically so much but it seems can count
on larger stable development community)
Your and other pylons users advices are very much welcome on those
questions
Thank you again
Daniel
Graham Higgins
Hash: SHA1
On 4 Jun 2010, at 12:09, daniel wrote:
> Actually they are scaring largely much behind authkit
Fortunately, it'd be relatively easy to swap out Authkit in favour of
a different auth'n'auth implementation if required, so there's not too
much to worry about there.
> my questions are :
(timely, I'd say)
> 1. Is still wise starting new long term projects based on Pylons ?
In my technical opinion [1], you need have no doubts on that score. I
view Pylons as an excellent choice for a web app development framework
in both the short and the long term. And, as we have seen recently on
this list [2], it has had some significant, hitherto-unadvertised,
take-up by some serious players.
James' direct involvement with Pylons development would seem to have
ceased a couple of years ago (about the same time he wrote the text on
that page, I suspect). You may wish to ascertain this for yourself by
looking through the commit records in the Pylons project development
history here: <http://bitbucket.org/bbangert/pylons/changesets>
The fact that Pylons development has continued apace and unaffected
since then stands as its own attestation to the cohesion, skill and
commitment of Ben, Phil, Ian, Mike and the other (all-too-often-
unsung) contributors from the community.
> 2. How strong and motivated remains the Pylons development community ?
(see above but ..) I'd say "very" and I'd also say that the strength
of motivation is reasonably immediately discernible from public
sources [2, again]. There's a lot of informal background scattered
across posts to this list and if you have specific concerns you might
find some reassurance there.
One particular characteristic of this community which I personally
appreciate (but which may act to mislead people at times) is a
distinct and deliberate absence of evangelism. IMO, that attests to a
very level-headed engineering perspective and a solid understanding of
where Pylons is located in the landscape of Python-based web app
development frameworks.
(Again, personally ...) I decided to reinforce my own commercial
commitment to Pylons with an investment of my time in contributing to
Pylons' development (mainly documentation and bug-fixing). I've also
learned, from personal communication with others in the Pylons-using
community, that there is a consistent and persistent level of interest
in helping to support the broad-scale Pylons effort by relieving the
dev team of some of the less technically-demanding chores but nothing
concrete has emerged yet --- we all have day jobs :-)
> 3. Which are, if any, the long term python web frameworks to
> eventually consider as alternative to pylons ? (should I re-evaluate
> django , which I don't like technically so much but it seems can count
> on larger stable development community)
In the absence of the context of a set of requirements, recommendation
turns into profitless speculation, so I shall evade the issue entirely
and simply provide a link to key info: <http://wiki.python.org/moin/WebFrameworks
>
Amongst the frameworks where I "know" (in the modern, net sense of the
term) the developers: TurboGears deserves a half-facetious mention
(half-facetious because it's based on Pylons ... but see [3]).
Agendaless' repoze.bfg [4] is worth your attention, as is Grok [5].
And Plone remains a serious candidate.
You will probably be interested in Marco, a speculative successor to
Pylons/BFG (ono).
Here's the repos overview <http://bitbucket.org/chrism/marco/overview>
and here's some ill-organised-but-at-least-collated-in-one-spot
narrative background: http://bel-epa.com/notes/Marco/
HTH.
[1] http://bel-epa.com/gjh/cv.pdf
[2] http://groups.google.com/group/pylons-discuss/browse_thread/thread/faf85d2f3e540244#
[3] http://blip.tv/file/get/Pycon-PyCon2010HowPythonTurboGearsAndMongoDBAreTransformingSou959.mp3
[4] http://bfg.repoze.org/
[5] http://grok.zope.org/
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkwI9d8ACgkQOsmLt1Nhivx9CwCbBfMt17yieT9w+xISrDprN/ln
Q/EAnRo6fBtxe5oO6op+GGT2litj2iECiQCVAgUBTAj131nrWVZ7aXD1AQJSWQP+
OqH/ILK6C9aRUHbxmdyfm0IBAPU9bEXuFgaB9d2tysXre/mobMSNAg9Qz/4DKCnb
DCwqL0Qin6bNgphoX9gZArCNqpOgQJXOuZlHTc8xCK2YEO/LUx3cSTVIUiUlBD9S
BYS1l6/6tsM47QwuPfnbmIIkk4FWJYQTvlfqAVhd66Y=
=6+Vk
-----END PGP SIGNATURE-----
daniel
very interesting and helpful overview
I decided to test more and stay with pylons at least for the current
and next few projects
By the way web2py was not mentioned in the list. Have you had any
chance to test it ?
cheers
daniel
> [3]http://blip.tv/file/get/Pycon-PyCon2010HowPythonTurboGearsAndMongoDBA...
Graham Higgins
Hash: SHA1
On 4 Jun 2010, at 15:20, daniel wrote:
> I decided to test more and stay with pylons at least for the current
> and next few projects
Hope it all goes swimmingly. If, as things progress, you find yourself
getting comfortable with a particular starting-out setup, Shabti
itself provides an example of how you can set up your own customized
project templates so that you can simply crank the handle and generate
more fully-instantiated apps. Shabti was forked from the tesla-pylons-
elixir project on Googlecode, an earlier speculative piece of work co-
authored by Ben and which, with just three templates, is probably a
clearer example of template customisation than the Shabti hordes.
> By the way web2py was not mentioned in the list. Have you had any
> chance to test it ?
I haven't tried web2py. My choice of framework was constrained by a
(self-imposed) requirement for high degree of freedom of choice over
approaches to storage - basically I wanted to be able to dabble with a
variety of persistences other than standard RDBMS, e.g. native XML dbs
(eXist) and RDF triple stores (OpenRDF)). To that end, Pylons was a
natural choice for me.
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkwJuq4ACgkQOsmLt1NhivxTfQCguWr1v2DuvlBidDqZioFJcQrP
ZQQAniac5L2x+hFn9HcX3FQ+nUw6+ycqiQCVAgUBTAm6rlnrWVZ7aXD1AQJU8wP8
CQZiNXzXVItFp2lwY2JhgFDoyABRlT8jHBPTxmtGgKnE1tB4MZH3nqs8HEq2o6Zc
9vg4QHPqxXvQesEwb1mtyEwdnW66xHFLEbk2HoYZgYQ2G9HdVsjyN3Gl5t/ozqbU
sxB7U9DjH8H+BbqQ/c5MBRZojsIcvAnOV1F/N9+p9DQ=
=N8HZ
-----END PGP SIGNATURE-----
Mike Orr
> I would recommend that all developers who are currently using AuthKit (or
> who plan to do so) should read and inwardly digest the statements on this
> page:
>
> <http://jimmyg.org/work/code/index.html>
>
> in which James lists those of his Python modules that are currently
> maintained and those which he is personally moving away from:
>
> 1. "Currently maintained Python modules:" (the list does not include
> authkit)
>
> 2. "Phasing out of my own projects:
> * Pylons - I'm using Flows ... instead.
> * FormBuild 1 and 2 - use FormBuild 3 instead.
> * AuthKit - I'm using [... other packages ... ] instead."
This is consistent with what James has been telling me over the past
year. I guess we should take AuthKit off the recommendation list and
just say it's an ex-solution. Repoze.who/what does essentially the
same but in a more modular way, and is the only one that has gained
acceptance by several frameworks.
On Fri, Jun 4, 2010 at 4:09 AM, daniel <dani...@orange.fr> wrote:
> After a look at <http://jimmyg.org/work/code/index.html> , where
> Pylons appears in the list of phased out projects (by the co-founder,
> although it seems there is still a community maintaining the project)
> and where I can read the following :
> « Phasing out of my own projects: Pylons - I'm using Flows (which I
> absolutely love) instead. It corrects all the problems with WSGI and
> Pylons which I discovered when writing the Pylons Book and is a
> complete re-write of the whole codebase and core dependencies from
> scratch, with complete conceptual integrity and with a far more
> modular architecture than even Pylons »,
James co-founded Pylons with Ben in 2005 because it met their needs at
the time. They (or at least Ben) were extending Myghty (a template
engine) with frameworkish features, and that clearly was not a
long-term solution. Paste was new at the time, and looking for a
full-stack framework to go on top of it, and Pylons became it. But
writing a book makes you acutely aware of the pros and cons of a
framework because you have to explain it in full detail (and justify
the bad parts :). That's why I stared but eventually abandoned a book
on using Pylons with App Engine. App Engine's early flaws just made it
really hard, and by the end I felt like, would I really use App Engine
myself, and if I did, wouldn't I be better off with one of the small
WSGI frameworks that was designed for App Engine?
After the Pylons book was published, James began working on something
that wasn't even a recognizable web framework, much less WSGI
compliant. I didn't understand it so I can't explain it. If Flows is
it, it may be something too different to just drop in place as a WSGI
framework.
> my questions are :
>
> 1. Is still wise starting new long term projects based on Pylons ?
> 2. How strong and motivated remains the Pylons development community ?
> 3. Which are, if any, the long term python web frameworks to
> eventually consider as alternative to pylons ? (should I re-evaluate
> django , which I don't like technically so much but it seems can count
> on larger stable development community)
Ben and I are using Pylons in production, and I've been spreading it
among the programmers at my organization. We'll be maintaining and
upgrading those applications for the next few years at least. Phillip
Jenvey has done a lot of work this past year to get Pylons to run on
Jython. Ian Bicking has never used Pylons much himself but remains an
indirect supporter, maintaining half of its dependencies. And the
TurboGears folks tell us what they need, or when something breaks.
I know Ben and myself have been looking beyond Pylons to see what
might be better, but there's nothing concrete at this point, just some
ideas. I originally chose Pylons because it's modular to the core. I
got sick of rewriting applications when they outgrew their framework.
Marco promises to extend that modularization into the Pylons core,
although it sounds like Ben has something non-Marcoish in mind too.
But the zen of Pylons is, "How much can you change before it's not
Pylons anymore?" It's not PasteDeploy or Routes or Beaker or Mako
because those are all optional. To me it's PylonsApp. If you replace
PylonsApp or subclass it so much it's unrecognizable, then it would be
hard to call the thing Pylons. But now we're looking at modularizing
PylonsApp itself. So if I someday wrote my own SOPless dispatcher and
stricter Routes and non-INI front end, would that still be Pylons? It
would interoperate with most of Pylons' components and would adhere to
the spirit of Pylons, so to me it would be, even if had a different
name.
All the WSGI developers have been sprinting together for the past two
or three years. So to us it's one family of frameworks, not
disconnected islands. The islands are Django, Twisted, Plone, and
Zope. (Zope the entire product, not Repoze or BFG.)
On Fri, Jun 4, 2010 at 5:47 AM, Graham Higgins <gjhi...@gmail.com> wrote:
> One particular characteristic of this community which I personally
> appreciate (but which may act to mislead people at times) is a distinct and
> deliberate absence of evangelism. IMO, that attests to a very level-headed
> engineering perspective and a solid understanding of where Pylons is located
> in the landscape of Python-based web app development frameworks.
It's a personality thing probably. The Pylons developers like to
program more than they like to market. We've also suppressed marketing
so as not to distract from finishing 1.0. Now that that's done, you'll
see development slow down, fewer changes in Pylons, and more emphasis
on marketing.
But I think we've agreed that Django has overmarketed, overpromised,
and gets extremely insistent at times, and we don't want to do that. I
don't know how much of it is due to the core Django developers
(because they're nice to us :), or how much is fanboys and marketroids
on the fringes of the developer base/userbase. But the Pylons tendency
is more to keep our heads down and write code, and let people come to
us. Because that's how we all came to Pylons ourselves.
We know we need somebody with good marketing experience, but we know
we're not it. So we're just waiting for somebody to say, "I'm that
[marketing] person."
--
Mike Orr <slugg...@gmail.com>
daniel
really appreciate because it helps in getting a better understanding
of the full picture. I personally think it is always good
transparently sharing background, reasons of choices, pros and cons
about a topic.
Also I like your suggestion for a clear statement about phased-out
packages (authkit in this case or maybe others). It would give to new
pylons adopters a safe feeling, which is not the case when they
discover the obsolescence of a package through posted comments.
So to my view the second rule in marketing pylons (the first is in
line with what you say are already doing: write good code with long
term in mind) is to make clear, transparent and frequent
communications on both bad and good recommendations, so that pylons
adopters feel always comfortable. The fact that pylons allows for
choosing from a broad range of solutions does not contrast with giving
a structured information about past good and bad experiences. If
authkit has not fitted most of the last pylons experiences, it should
be said in a clear and strong manner, because it is beneficial to
pylons users, especially to pylons newcomers. For instance I ended to
the conclusion of using instead repoze.who/what after a week of
googling and pylons-discuss, it could have been a matter of a few
minutes if it were clearly recommended on pylons site
I've been in electronic products marketing for more or less the last
20 years and I'd be glad helping one day in some way in marketing
pylons as soon as I reach myself a decent technical knowledge about
pylons (i.e. go through a few pylons based projects)
cheers
daniel
On Jun 5, 6:16 am, Mike Orr <sluggos...@gmail.com> wrote:
> > I would recommend that all developers who are currently using AuthKit (or
> > who plan to do so) should read and inwardly digest the statements on this
> > page:
>
> > <http://jimmyg.org/work/code/index.html>
>
> > in which James lists those of his Python modules that are currently
> > maintained and those which he is personally moving away from:
>
> > 1. "Currently maintained Python modules:" (the list does not include
> > authkit)
>
> > 2. "Phasing out of my own projects:
> > * Pylons - I'm using Flows ... instead.
> > * FormBuild 1 and 2 - use FormBuild 3 instead.
> > * AuthKit - I'm using [... other packages ... ] instead."
>
> This is consistent with what James has been telling me over the past
> year. I guess we should take AuthKit off the recommendation list and
> just say it's an ex-solution. Repoze.who/what does essentially the
> same but in a more modular way, and is the only one that has gained
> acceptance by several frameworks.
>
> > One particular characteristic of this community which I personally
> > appreciate (but which may act to mislead people at times) is a distinct and
> > deliberate absence of evangelism. IMO, that attests to a very level-headed
> > engineering perspective and a solid understanding of where Pylons is located
> > in the landscape of Python-based web app development frameworks.
>
> It's a personality thing probably. The Pylons developers like to
> program more than they like to market. We've also suppressed marketing
> so as not to distract from finishing 1.0. Now that that's done, you'll
> see development slow down, fewer changes in Pylons, and more emphasis
> on marketing.
>
> But I think we've agreed that Django has overmarketed, overpromised,
> and gets extremely insistent at times, and we don't want to do that. I
> don't know how much of it is due to the core Django developers
> (because they're nice to us :), or how much is fanboys and marketroids
> on the fringes of the developer base/userbase. But the Pylons tendency
> is more to keep our heads down and write code, and let people come to
> us. Because that's how we all came to Pylons ourselves.
>
> We know we need somebody with good marketing experience, but we know
> we're not it. So we're just waiting for somebody to say, "I'm that
> [marketing] person."
>
> --
Mike Orr
> I wish thanking you for this piece of history about pylons, which I
> really appreciate because it helps in getting a better understanding
> of the full picture. I personally think it is always good
> transparently sharing background, reasons of choices, pros and cons
> about a topic.
Here's the full history. I see it hasn't been updated since 2008, but
it covers the early years.
http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Historical+Timeline
Other bits about the Pylons community and marketing plans, all out of
date probably, are in the Pylons Community section of the wiki.
http://wiki.pylonshq.com/display/pylonscommunity/Home
> Also I like your suggestion for a clear statement about phased-out
> packages (authkit in this case or maybe others). It would give to new
> pylons adopters a safe feeling, which is not the case when they
> discover the obsolescence of a package through posted comments.
I changed the main auth page and deleted the AuthKit pages in the
Cookbook. They mostly referred to the section in the Pylons book or
elaborated it. So those who see it in the book will get the author's
advice, and those who don't find that chapter needn't worry about it.
There are 18 pages of other references to it in the wiki but it would
take way too long to go looking all those up and posting warning
messages. We need to promote the main auth page as much as possible.
http://wiki.pylonshq.com/display/pylonscookbook/Authentication+and+Authorization
I don't know how many new users realize that the Pylons Cookbook
section in the wiki is the place for unofficial documentation, and
that the pages listed on the main page or underneath portal pages like
the auth page are most likely to have the most up-to-date advice.
(But unfortunately it's not all up to date, and we need to give the
wiki a good spring cleaning, but nobody has time to. I find it easier
to just answer questions on the list.
> So to my view the second rule in marketing pylons (the first is in
> line with what you say are already doing: write good code with long
> term in mind) is to make clear, transparent and frequent
> communications on both bad and good recommendations, so that pylons
> adopters feel always comfortable. The fact that pylons allows for
> choosing from a broad range of solutions does not contrast with giving
> a structured information about past good and bad experiences. If
> authkit has not fitted most of the last pylons experiences, it should
> be said in a clear and strong manner, because it is beneficial to
> pylons users, especially to pylons newcomers. For instance I ended to
> the conclusion of using instead repoze.who/what after a week of
> googling and pylons-discuss, it could have been a matter of a few
> minutes if it were clearly recommended on pylons site
Well, i think the developers didn't want to disrespect James because
he was a founder and AuthKit was his creation. Certainly there were
users who took it into their hands to steer people away from AuthKit.
I kept reminding James that if he was going to promote AuthKit, he
needed to support it. I think he finally gave up combating all its
negative publicity and just abandoned it himself. I wish he'd made a
more definitive disavowal of it, then we could have taken it off the
recommended list a while ago.
As for other components that may be in similar circumstances, you
bring up a good point. I can't think of any other packages that are
similarly unlucky. At least none that anybody's using nowadays. I
trust nobody's using Pylons 0.9.5 anymore and the last people are
getting off 0.9.6.
I myself am very happy with Mako, and my SQLAlchemy 0.6 upgrade has
been just fine after changing a few deprecated usages. Repoze.who/what
looks quite extensive but I find it a bit difficult to keep track of
all the parts. I finally ended up making my own demonstration site
step by step following the various tutorials and application
templates. But I needed to do a hybrid form of LDAP+database auth that
didn't really fit with who's structure, and then I discovered the
repoze.who-LDAP module is unmaintained. I think if I go back to
who/what I'll write my own identity plugin (if that's the right term)
rather than trying to shoehorn my needs into the existing LDAP,
SQLAlchemy, and identity-properties plugins. But my needs are rather
specific and unusual.
I haven't used ToscaWidgets or FormAlchemy or its descendants but they
seem capable and well-supported. TW has always been lacking in the
documentation area; I don't know if that's been remedied, but I did
take a great tutorial in it at PyCon by Chris Perkins who's a TW guru,
and it seems quite powerful, though it is rather complex to understand
and do you really want all those dependencies? Or rather, how central
are generated forms to your application? So far I haven't needed them.
I'm sure you've noticed FormEncode docs aren't very clear and I
finally, *finally* , have time to work on a manual for it, yippee.
> I've been in electronic products marketing for more or less the last
> 20 years and I'd be glad helping one day in some way in marketing
> pylons as soon as I reach myself a decent technical knowledge about
> pylons (i.e. go through a few pylons based projects)
That would be great. If you see a niche you can fill, or a suggestion
to make, please feel free.
--
Mike Orr <slugg...@gmail.com>
Marius Gedminas
> Here's the full history. I see it hasn't been updated since 2008, but
> it covers the early years.
>
> http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Historical+Timeline
Quote:
"Nowadays a third product called WebWare has appeared, the rendering
engine in the Safari web browser. This was forked from KDE's KHTML
renderer and is now being re-merged under the WebWare name. Konqueror,
wxPython, and GNOME all use it or soon will."
Doesn't this actually refer to WebKit rather than WebWare? (In which
case it wouldn't be a "third product".)
Marius Gedminas
--
Ambition is a poor excuse for not having enough sense to be lazy.
Mike Orr
> On Sat, Jun 05, 2010 at 01:39:20AM -0700, Mike Orr wrote:
>> Here's the full history. I see it hasn't been updated since 2008, but
>> it covers the early years.
>>
>> http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Historical+Timeline
>
> Quote:
>
> "Nowadays a third product called WebWare has appeared, the rendering
> engine in the Safari web browser. This was forked from KDE's KHTML
> renderer and is now being re-merged under the WebWare name. Konqueror,
> wxPython, and GNOME all use it or soon will."
>
> Doesn't this actually refer to WebKit rather than WebWare? (In which
> case it wouldn't be a "third product".)
Oh, I guess it;s worded wrong. WebWare's main component is a framework
called WebKit, so that's where the commonality would be.
--
Mike Orr <slugg...@gmail.com>
Gustavo Narea
On Jun 5, 9:39 am, Mike Orr <sluggos...@gmail.com> wrote:
> Repoze.who/what
> looks quite extensive but I find it a bit difficult to keep track of
> all the parts.
I'm trying to make things more clear lately, and hopefully that
wouldn't be a problem when the development versions of repoze.who and
repoze.what come out. For (potential) users of repoze.who 1.0 and
repoze.what 1.0, this might be a good starting point:
http://gustavonarea.net/blog/posts/repoze-auth/
> I finally ended up making my own demonstration site
> step by step following the various tutorials and application
> templates. But I needed to do a hybrid form of LDAP+database auth that
> didn't really fit with who's structure, and then I discovered the
> repoze.who-LDAP module is unmaintained. I think if I go back to
> who/what I'll write my own identity plugin (if that's the right term)
> rather than trying to shoehorn my needs into the existing LDAP,
> SQLAlchemy, and identity-properties plugins. But my needs are rather
> specific and unusual.
changed my mind and, although I won't develop it actively anymore, I'm
accepting patches now. For example, one of the things you needed back
then is available in v1.1a1 (the username alone instead of the full
DN):
http://code.gustavonarea.net/repoze.who.plugins.ldap/Changes.html#alpha-1-2010-01-03
Cheers,
- Gustavo.
Mike Orr
> Hello, Mike et al.
>> I finally ended up making my own demonstration site
>> step by step following the various tutorials and application
>> templates. But I needed to do a hybrid form of LDAP+database auth that
>> didn't really fit with who's structure, and then I discovered the
>> repoze.who-LDAP module is unmaintained. I think if I go back to
>> who/what I'll write my own identity plugin (if that's the right term)
>> rather than trying to shoehorn my needs into the existing LDAP,
>> SQLAlchemy, and identity-properties plugins. But my needs are rather
>> specific and unusual.
>
> You may also consider sending some patches for that plugin. I've
> changed my mind and, although I won't develop it actively anymore, I'm
> accepting patches now. For example, one of the things you needed back
> then is available in v1.1a1 (the username alone instead of the full
> DN):
> http://code.gustavonarea.net/repoze.who.plugins.ldap/Changes.html#alpha-1-2010-01-03
Ok, I'll see, but I'm not sure how generally useful they'd be. My
problem is the following.
1) Some users are internal and have LDAP accounts, and their roles are
calculated from their LDAP properties. (Roles = metadata for the
identity object, which will later be used for authorization. It also
includes record IDs for users who have permission only to specific
records.)
2) Some users are external, so their username, password, and roles are
in a SQL database.
3) Some users are hybrid, in that their authentication is LDAP but
their roles are in the database. (They have higher permissions than
their LDAP properties would indicate.) This is indicated by a database
record with a null password.
4) I distinguish internal vs external users by the syntax of the
username. Internal users have to enter their full email address,
because the domain indicates they're internal (i.e., authenticate via
LDAP). This is to prevent two different users from having the same
username, because there are thousands of LDAP users and we don't know
when somebody joins or leaves or what future usernames will be. But
we're getting pushback from users that they don't want to type the
domain, which is different than how they log into other applications
(those that don't have external users). So I'm thinking about just
choosing a priority; i.e., consult the database first or consult LDAP
first, and then deal with identical usernames when/if users complain
they can't log in. (We could also use a separate form field to
indicate internal/external, but users wouldn't like that either.)
6) The LDAP plugin puts the user's properties into the identity object
I think, but I don't want to force the application to process the raw
LDAP properties all the time, because they're obscure and squirrely. I
want it to calculate the roles right when they log in, in the same
format used for external users. It looks like I'd have to write a
plugin for that.
7) The normal cascading seems to try one authentication method first,
and use that if it succeeds, and otherwise try the other. It doesn't
allow for the hybrid case where both succeed and their metadata is
merged in the identity object. (Full name from LDAP, roles from
database.) That's where it looks like I'd have to write a custom
plugin that spans three or four of the standard plugins.
8) The whole identity structure (how the metadata is created and used)
is not the way my application works. I'm not sure if changing the
structure would lead to a reasonable compromise.
So #7 and #8 may lead to generic patches, but I'm not sure if they'd
be generic enough to be generally useful. On the other hand, I think
other people may also benefit from a more flexible form of cascading
and metadata handling.I'm not sure if I can design one that would make
everybody happy, but if I can I'll send it in.
--
Mike Orr <slugg...@gmail.com>
Gustavo Narea
I agree it's not a common situation, but I think some things are
simpler than they seem; for example, if you have two metadata plugins
(e.g., SQL and LDAP), they both would be used regardless of the
successful authentication method.
If I got it all right, you'd need at least 5 repoze.who plugins:
1 identifier, the one that handles the login form.
1 LDAP authenticator.
1 SQL authenticator.
1 LDAP metadata provider.
1 SQL metadata provider.
Of which only the identifier and the LDAP metadata provider should be
customized. The identifier would be customized in order to remove
everything after the at sign (e.g., "gus...@example.org" becomes
"gustavo"). And the LDAP metadata provider would be customized to
filter/process the attributes retrieved. This would be translated into
Python as:
http://pastebin.com/BGv7i5cU
Or, if you want to make sure that it's save to remove everything after
the at sign for internal users, you can customize both authenticators:
http://pastebin.com/W35kJmeG
I think that way everything will work.
HTH,
- Gustavo.
Mike Orr
> Hello, Mike.
>
> I agree it's not a common situation, but I think some things are
> simpler than they seem; for example, if you have two metadata plugins
> (e.g., SQL and LDAP), they both would be used regardless of the
> successful authentication method.
>
> If I got it all right, you'd need at least 5 repoze.who plugins:
> 1 identifier, the one that handles the login form.
> 1 LDAP authenticator.
> 1 SQL authenticator.
> 1 LDAP metadata provider.
> 1 SQL metadata provider.
So that would require two LDAP queries or two SQL queries for every login?
That brings up another issue I forgot. The LDAP plugin seems to assume
a long-running connection that will never be broken, and has no
provision to reconnect. (The constructor takes a connection rather
than a factory.) I don't know if LDAP is as likely to close idle
connections as MySQL is, but our server does go down occasionally. In
my app, I connect to LDAP separately for each login attempt. I suppose
that might increase the latency, but it does mean I don't have to
worry about reconnecting. It should probably start with a long-lived
connection but reconnect gracefully.
--
Mike Orr <slugg...@gmail.com>
Gustavo Narea
> So that would require two LDAP queries or two SQL queries for every login?
The way I suggested, yes.
If that's an issue, you could extend the authenticators (or create your own)
so that you retrieve everything in one go, putting the metadata in a temporary
location in the WSGI environ and then making a metadata provider that moves it
to the identity dict.
> That brings up another issue I forgot. The LDAP plugin seems to assume
> a long-running connection that will never be broken, and has no
> provision to reconnect. (The constructor takes a connection rather
> than a factory.) I don't know if LDAP is as likely to close idle
> connections as MySQL is, but our server does go down occasionally. In
> my app, I connect to LDAP separately for each login attempt. I suppose
> that might increase the latency, but it does mean I don't have to
> worry about reconnecting. It should probably start with a long-lived
> connection but reconnect gracefully.
The plugin only uses the "simple_bind_s" method of the connection object, so
you could define a class with that method so that you can connect to the LDAP
server on every login attempt.
Or, the plugin could be modified to do it automatically when required. I can
apply a patch to do it.
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |