PAULA: bringing Zope 3's authentication to Plone and beyond
Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The code is not very interesting right now, but now would be the time to take any influence on what will be created during the next month - I am planning to continue to work on the project after the SoC. I will keep you updated on major advancements of the code. regards florian
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate.
Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who.
Previously Philipp von Weitershausen wrote:
Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate.
Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who.
Doesn't repoze already have a PAS plugin to do just that? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Philipp von Weitershausen wrote:
Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate. Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who.
Doesn't repoze already have a PAS plugin to do just that?
Ah, that's right: http://svn.agendaless.com/Products.whoopass. That doesn't mean it could be integrated better, though, for instance UI-wise...
On Thu, Jul 10, 2008 at 05:01:49PM -0400, Philipp von Weitershausen wrote:
Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate.
Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who.
The main goal of the project is: to enable non-AT content as source for users and groups! On that base it was accepted as a GSOC project for Plone. The original idea was to extend membrane; after looking into it more closely, my mentor (Jens W. Klein) and me agreed, that doing it from scratch, using PAU is easier, future plugin writing will be easier and the whole Zope3 community could benefit from it, too. That is why the original proposal was discussed only on plone-dev and why I sent the mail now to zope-dev as well. Nobody has to use it later ;) but the circle of people who could benefit from my project, if they would like to, is definitely bigger doing it via PAU. And those people who want non-AT content-based users and groups, will get a fully functional PAU as well, which again they don't need to use for anything further, if they don't want to... florian
On Thu, Jul 10, 2008 at 10:56:19PM +0200, Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
The one thing I am missing is: why?
Well, Zope moved onwards from PAS to PAU and I think Plone should too, because: - PAU is way more pythonic and cleaner than PAS/PlonePAS, it is easier to write stuff for PAU; - we should use as much as possible of Zope3 and avoid custom solutions, increasing the mutual benefit of all Zope3-based projects. I am writing a PlonePAS plugin, that makes the world of PAU available to Plone, i.e. we can profit from whatever is available for PAU right now and becomes available in the future. Further, I am enabling pure zope3 content as source for users and groups, not only usable for Plone, but for all Zope3-based projects. And the resulting code is cleaner and easier to maintain and understand. For me, it is more a question of: why not?
PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins.
PAU is doing things different than PlonePAS/PAS, but I don't see how the current functionality of PlonePAS/PAS could not be achieved with PAU? Yes, there are a lot more plugins for PAS than for PAU, but that does not contradict, writing another PAS plugin, that makes all future auth plugin writing easier. Whether PAU could/should replace PlonePAS/PAS at some point, is a completely different story.
It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate.
At least, two months ago, when I started with my project, membrane did not support non-AT content and I don't know of any other project doing it; b-org is all archetypes. florian
Well, Zope moved onwards from PAS to PAU and I think Plone should too, because:
It seems like just yesterday that PAS offered the promise of being the nice clean way forward for authentication, and even offered a path to Zope3. I've been subscribed to zope-dev since then, but somehow the anointing of PUA escaped my attention. It seems like plenty of people in these -dev communities aren't aware the world has shifted again under them, so I pity the poor soul who attempts to use/install/configure this software.
I am writing a PlonePAS plugin, that makes the world of PAU available to Plone
Hopefully you will finish by the time PAU is considered ugly/unpythonic/whatever enough to replace <wink/sigh> The sands constantly shifting under our feet sounds like a much bigger problem than whatever was wrong with PAS, or whatever will be decided is wrong with PUA (and repeat ad-nauseam for the variety of successors.) Mark
On Jul 12, 2008, at 09:33 , Mark Hammond wrote:
Well, Zope moved onwards from PAS to PAU and I think Plone should too, because:
It seems like just yesterday that PAS offered the promise of being the nice clean way forward for authentication, and even offered a path to Zope3. I've been subscribed to zope-dev since then, but somehow the anointing of PUA escaped my attention.
It has not been anointed. Two people (the OP and his GSOC mentor) have made a (IMHO misguided) decision. That's all. jens
Mark Hammond wrote:
Well, Zope moved onwards from PAS to PAU and I think Plone should too, because:
It seems like just yesterday that PAS offered the promise of being the nice clean way forward for authentication, and even offered a path to Zope3. I've been subscribed to zope-dev since then, but somehow the anointing of PUA escaped my attention.
I think you've misunderstood slightly here ... PAS was and is a Zope 2 user folder implementation. It pre-dates Zope 3 (at least as we know it now). PAU is a Zope 3 authentication infrastructure. I suspect it's inspired by PAS, but it isn't "PAS 2.0", or an "anointed successor" to PAS. I find it interesting that Florian is planning to make it possible to use PAU utilities in PAS. I'm somewhat less convinced that it would be difficult to make membrane AT-independent. There isn't much AT specific stuff in membrane, as far as I can recall. I can't make a judgement as to whether PAU could bring additional benefits, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
I think you've misunderstood slightly here ... PAS was and is a Zope 2 user folder implementation. It pre-dates Zope 3 (at least as we know it now).
I was referring to the thread at http://mail.zope.org/pipermail/zope-pas/2004-September/000086.html, entitled "[Zope-PAS] Challengers (and Zope 3)" - but I do admit I haven't been keeping a close eye on Zope3 since then so things may have changed (but the claim PAS predates Zope 3 seems suspect in the context of that thread, unless Zope 3 has changed since then in a way it no longer means Zope 3 ;) Cheers, Mark
Mark Hammond wrote:
I think you've misunderstood slightly here ... PAS was and is a Zope 2 user folder implementation. It pre-dates Zope 3 (at least as we know it now).
I was referring to the thread at http://mail.zope.org/pipermail/zope-pas/2004-September/000086.html, entitled "[Zope-PAS] Challengers (and Zope 3)" - but I do admit I haven't been keeping a close eye on Zope3 since then so things may have changed (but the claim PAS predates Zope 3 seems suspect in the context of that thread, unless Zope 3 has changed since then in a way it no longer means Zope 3 ;)
Sorry, I may've gotten my history mixed up a little here, but in any case, I think the point remains: no-one's said (nor not said) that PAS is to be deprecated in favour of PAU in a Zope 2/CMF/Plone context at least. So I don't think you missed that. ;-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin quoting me:
I was referring to the thread at http://mail.zope.org/pipermail/zope-pas/2004-September/000086.html, entitled "[Zope-PAS] Challengers (and Zope 3)" ...
Sorry, I may've gotten my history mixed up a little here, but in any case, I think the point remains: no-one's said (nor not said) that PAS is to be deprecated in favour of PAU in a Zope 2/CMF/Plone context at least. So I don't think you missed that. ;-)
Thanks for the clarification. However, while not wanting to extend this debate any more than necessary, I'm still wondering if *my* point remains valid in the broader "zope x" context: Is PAS still alive and preferred for Zope3? Or more generally, is there any reasonable strategy for sticking with PAS in Zope2 while also keeping the door open to Zope3? I hope so - but I fear that for fairly obscure reasons Zope2 and Zope3 have diverged in this specific area, in a way that isn't in the long term interests of people investing in Zope technologies... Again, I add the disclaimer that my zope3 knowledge is less than - err - ideal <wink>, so it is likely I'm talking out of my proverbial, but I'm interested nonetheless... Cheers, Mark
Previously Mark Hammond wrote:
Martin quoting me:
I was referring to the thread at http://mail.zope.org/pipermail/zope-pas/2004-September/000086.html, entitled "[Zope-PAS] Challengers (and Zope 3)" ...
Sorry, I may've gotten my history mixed up a little here, but in any case, I think the point remains: no-one's said (nor not said) that PAS is to be deprecated in favour of PAU in a Zope 2/CMF/Plone context at least. So I don't think you missed that. ;-)
Thanks for the clarification.
However, while not wanting to extend this debate any more than necessary, I'm still wondering if *my* point remains valid in the broader "zope x" context:
Is PAS still alive and preferred for Zope3? Or more generally, is there any reasonable strategy for sticking with PAS in Zope2 while also keeping the door open to Zope3? I hope so - but I fear that for fairly obscure reasons Zope2 and Zope3 have diverged in this specific area, in a way that isn't in the long term interests of people investing in Zope technologies...
Zope3 has never supported PAS and I doubt it ever well. Zope2 has never supported PAU and the Zope2 world in general seems to be quiet happy with sticking to PAS. Since Zope3 is not a successor to Zope2 but a completely different thing I do not think this is problematic. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Zope3 has never supported PAS and I doubt it ever well.
That is a shame - the thread I referred to shows that Jim was working on exactly that - it's a shame that never came to fruition (and indeed, its not clear why that attempt failed - should PAS have been fixed to make that transition possible?)
Since Zope3 is not a successor to Zope2 but a completely different thing I do not think this is problematic.
That too seems a shame to me. So if I found myself with an investment in Zope2 but was looking to the future, Zope3 will not even *attempt* to provide a smoother path for me than, say, moving to django or another alternative framework? I guess the fact the first 4 letters of "zope2" and "zope3" being the same did imply some sense of continuation in at least *some* things... (or, as usual, I may be missing something that is obvious to those closer to the metal than me as a somewhat external observer) Cheers, Mark
--On 13. Juli 2008 19:38:01 +0300 Mark Hammond <mhammond@skippinet.com.au> wrote:
Since Zope3 is not a successor to Zope2 but a completely different thing I do not think this is problematic.
That too seems a shame to me. So if I found myself with an investment in Zope2 but was looking to the future, Zope3 will not even *attempt* to provide a smoother path for me than, say, moving to django or another alternative framework?
How about GROK?
I guess the fact the first 4 letters of "zope2" and "zope3" being the same did imply some sense of continuation in at least *some* things...
That's reason why the term "zope 3" should be phased out and replaced with "Zope web components" or something similar. You're not the only one being confused by this. -aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Hammond wrote:
Zope3 has never supported PAS and I doubt it ever well.
That is a shame - the thread I referred to shows that Jim was working on exactly that - it's a shame that never came to fruition (and indeed, its not clear why that attempt failed - should PAS have been fixed to make that transition possible?)
Since Zope3 is not a successor to Zope2 but a completely different thing I do not think this is problematic.
That too seems a shame to me. So if I found myself with an investment in Zope2 but was looking to the future, Zope3 will not even *attempt* to provide a smoother path for me than, say, moving to django or another alternative framework?
I guess the fact the first 4 letters of "zope2" and "zope3" being the same did imply some sense of continuation in at least *some* things...
The original intent was to allow for transparent migration: the end result has been that Zope2 *uses* selected bits of Zope3, with no intent (going forward) that Zope2 will "wither away." Rather, we are gradually replacing various bits of Z2, where appropriate, with the Z3 equivalents. The entire debate here is about whether PAU is really an appropriate replacement for PAS, given that it doesn't support some use cases out of the box, and has a smaller set of available plugins.
(or, as usual, I may be missing something that is obvious to those closer to the metal than me as a somewhat external observer)
I wouldn't call the current state obvious. ;) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIejjk+gerLs4ltQ4RAnlWAJ48nu1VCyDIgmKs90xtT0uIZcG1YQCeJLDF Bmw9fc+PXq/JhJFLmrTERZg= =odMI -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Hammond wrote:
Well, Zope moved onwards from PAS to PAU
I doubt that seriously: I would venture that there are two orders of magnitude more users of PAS than PAU in production deployments. PAU was an attempt to port the PAS to a "component-centric" implementation, but it lost at least a couple of key features along the way: most notably, the ZCA provides no way to control the ordering of the invocation of the plugins.
and I think Plone should too,
- -1. I can see no benefit, except the myth (in the technical, anthropological sense) that a Z3-based rewrite of any arbitrary component must be superior to the thing it rewrites.
because:
It seems like just yesterday that PAS offered the promise of being the nice clean way forward for authentication, and even offered a path to Zope3. I've been subscribed to zope-dev since then, but somehow the anointing of PUA escaped my attention.
It seems like plenty of people in these -dev communities aren't aware the world has shifted again under them, so I pity the poor soul who attempts to use/install/configure this software.
PlonePAS still has some rough edges, as do some of the available plugins, but the underlying PAS is still a pretty nice way to do "local" user folders.
I am writing a PlonePAS plugin, that makes the world of PAU available to Plone
Hopefully you will finish by the time PAU is considered ugly/unpythonic/whatever enough to replace <wink/sigh>
The sands constantly shifting under our feet sounds like a much bigger problem than whatever was wrong with PAS, or whatever will be decided is wrong with PUA (and repeat ad-nauseam for the variety of successors.)
Heh, you sound almost as much like an "old fart" as I do. :) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIePdV+gerLs4ltQ4RAqUyAJ0VVg2n2xydtNwlMR2WvF8JAJKoXQCfa60M Mrsp26qNnmHxOkjsG90SaJ8= =e2pa -----END PGP SIGNATURE-----
Tres Seaver wrote:
Mark Hammond wrote:
Well, Zope moved onwards from PAS to PAU
I doubt that seriously: I would venture that there are two orders of magnitude more users of PAS than PAU in production deployments. PAU was an attempt to port the PAS to a "component-centric" implementation, but it lost at least a couple of key features along the way: most notably, the ZCA provides no way to control the ordering of the invocation of the plugins.
The ZCA may have no built-in way to control the ordering, but PAU surely does control the ordering. It keeps an ordered list of plugin names. These plugins can either be contained items in the PAU (like in PAS) or utilities for ICredentialsPlugin or IAuthenticatorPlugin.
--On 11. Juli 2008 18:04:16 -0700 Florian Friesdorf <flo@chaoflow.net> wrote:
On Thu, Jul 10, 2008 at 10:56:19PM +0200, Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *,
within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages.
All documents describing the project, as well as links to the code can be found here:
The one thing I am missing is: why?
Well, Zope moved onwards from PAS to PAU and I think Plone should too, because: - PAU is way more pythonic and cleaner than PAS/PlonePAS, it is easier to write stuff for PAU;
More pythonic or not...writing a PAS plugin is fairly easy and trivial. We have to maintain APIs that we were using for a long time for the sake of backward compatibility (for the sake of plone users and the sake of plone PAS developers). I want API stability. I don't want to change my code just because someone means that a layer would be nice. We already have enough various spots in side Plone where you have at least two choice for implementing things with different technologies..please not yet another such spot. Andreas
- we should use as much as possible of Zope3 and avoid custom solutions, increasing the mutual benefit of all Zope3-based projects.
On Jul 12, 2008, at 03:04 , Florian Friesdorf wrote:
On Thu, Jul 10, 2008 at 10:56:19PM +0200, Wichert Akkerman wrote:
The one thing I am missing is: why?
Well, Zope moved onwards from PAS to PAU
Huh? Zope 2 uses PAS. The Zope 3 folks have attempted to come up with a similar solution, but it's lagging in functionality and finish. Just because Zope 3 sprouts a similar technology to what Zope 2 is using does not automatically imply "Zope moves onwards to X". And it hasn't.
- we should use as much as possible of Zope3 and avoid custom solutions, increasing the mutual benefit of all Zope3-based projects.
I call BS here. PAS is not a "custom solution", it's much more of a standard than PAU is. The question remains, "why?". You're reinventing wheels for Zope 2 that do not need to be reinvented. One day when PAU has indeed surpassed PAS in terms of functionality and plugins then it may make sense. But not now. jens
Jens Vagelpohl wrote:
I call BS here. PAS is not a "custom solution", it's much more of a standard than PAU is.
The question remains, "why?". You're reinventing wheels for Zope 2 that do not need to be reinvented. One day when PAU has indeed surpassed PAS in terms of functionality and plugins then it may make sense. But not now.
I think it's worth displaying some sensitivity to the context of Google Summer of Code here. I too worry that PAULA may throw the baby (PAS) out with the bathwater. However, GSoC is an excellent incubator of R&D, and has secondary goals such as bringing more people into the community and engaging with students so that they become the future contributors of our projects. Shooing them down in flames is not going to help. I wish that some of these discussions had been had in the open so that more people could weigh in. However, most people who aren't used to the open source way (and plenty who are, even) find it difficult to address a whole community on a public mailing list and understand the nuances of the responses. That very thing is part of the learning curve that GSoC seeks to address. On balance, I think it's great that Florian is exploring new territory here. PAULA may or may become a part of Zope and/or Plone in the future. It may be that we use bits of it and let other bits evolve separately. It may be that it dies, but at least then we have a clear idea about what PAU is and what benefits it can bring. The notion of having a bridge component certainly sounds sensible to me. So, please, let's not be too harsh until we've seen the final product and given it a fair chance. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
"may or may become a part of Zope and/or Plone in the future". Well put Martin. ;) -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
Sidnei da Silva wrote:
"may or may become a part of Zope and/or Plone in the future". Well put Martin. ;)
Hah, obviously I meant "may or may not". :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Sat, Jul 12, 2008 at 02:04:32PM +0100, Martin Aspeli wrote:
I think it's worth displaying some sensitivity to the context of Google Summer of Code here. I too worry that PAULA may throw the baby (PAS) out with the bathwater.
However, GSoC is an excellent incubator of R&D, and has secondary goals such as bringing more people into the community and engaging with students so that they become the future contributors of our projects. Shooing them down in flames is not going to help.
I see my work clearly in the R&D area, too, and I would like to take it as an opportunity to get further involved with Plone and Zope development. Sorry, if I am kicking off flames on the way there ;)
I wish that some of these discussions had been had in the open so that more people could weigh in. However, most people who aren't used to the open source way (and plenty who are, even) find it difficult to address a whole community on a public mailing list and understand the nuances of the responses. That very thing is part of the learning curve that GSoC seeks to address.
point taken
On balance, I think it's great that Florian is exploring new territory here. PAULA may or may become a part of Zope and/or Plone in the future. It may be that we use bits of it and let other bits evolve separately. It may be that it dies, but at least then we have a clear idea about what PAU is and what benefits it can bring. The notion of having a bridge component certainly sounds sensible to me.
So, please, let's not be too harsh until we've seen the final product and given it a fair chance.
thank you very much for supporting my idea florian PS: Did you intentionally not post to plone-developer's? As all of them are on zope-dev, too?
Am Samstag, 12. Juli 2008 03:04 schrieb Florian Friesdorf:
On Thu, Jul 10, 2008 at 10:56:19PM +0200, Wichert Akkerman wrote:
Previously Florian Friesdorf wrote:
Hi *, PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins.
PAU is doing things different than PlonePAS/PAS, but I don't see how the current functionality of PlonePAS/PAS could not be achieved with PAU?
At first, I very much appreciate putting working into PAU. I personally use Zope3 only, so I have little experience with Zope2 and none with PAS, therefore I can't compare them. In my projects, I use PAU only, so I do have some experience with it. And my personal impression is, that PAU is a very interesting approach, but it has it's drawbacks. I would denote the following: 1) No way to pass PAU-related information to form-code: In PAU, the authentication is entirely done before user code, e.g. form handling etc. In my scenario, I have a login form (z3c.form based), which has two input fields that comply to z3c.form, so if the correct user data is inserted in these fields, I'm logged in. If login data is wrong, then the form has no way to find out, why the login process failed (e.g. "no such user", "wrong password", "no cookie support"). Moreover, my login form has a "Cancel" button, which should cancel the login process. If correct login data is entered, and "Cancel" is pressed, the user is logged in nevertheless. 2) Lack of documentation: The entities "Principal, InternalPrincipal, PrincipalInfo" are very confusing to a newbie, I still don't get the "big picture". 3) Lack of plugins: No plugin for URL-rewriting, e.g. cookie-less browsers (retrieving auth-information from URL) etc. I personally needed to write an authentication plugin for a SQLAlchemy based RDB, and was confused a lot of how/why to create Principal / PrincipalInfo objects: Should I create my own Principal/PrincipalInfo objects in order to stuff information into them that my application needs? How excactly should I cache user data so that a single browser request does not lead to multiple RDB queries? And where in the big picture is the "User" entity? (It's probably the InternalPrincipal object, I assume)... PAU-based authentication now works for me to some degree, but it was a massive fight, and for my case, it seemed that the PAU flexibility simply led to complexity but was not flexible/thought out enough to support my specific, but relatively simple scenario. So I would very, very much suggest to dig into PAU first and fix those shortcomings before porting it to Plone/Zope2. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Mon, Jul 14, 2008 at 09:50:25AM +0200, Hermann Himmelbauer wrote:
(..) 1) No way to pass PAU-related information to form-code: In PAU, the (..)
As I using PAU within Plone and PlonePAS to handle the credential extraction and form stuff, I can't say anything about PAU's capabilities of doing that. However, I wrote it down and will eventually look into it.
2) Lack of documentation: The entities "Principal, InternalPrincipal, PrincipalInfo" are very confusing to a newbie, I still don't get the "big picture".
InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects.
3) Lack of plugins: No plugin for URL-rewriting, e.g. cookie-less browsers (retrieving auth-information from URL) etc.
I don't know about URL-rewriting, but you should be easily able to write your own credentials plugin to extract whatever you like from a request object.
I personally needed to write an authentication plugin for a SQLAlchemy based RDB, and was confused a lot of how/why to create Principal / PrincipalInfo objects: Should I create my own Principal/PrincipalInfo objects in order to stuff information into them that my application needs?
Most probably that could work.
How excactly should I cache user data so that a single browser request does not lead to multiple RDB queries? And where in the big picture is the "User" entity? (It's probably the InternalPrincipal object, I assume)...
You don't need InternalPrincipal objects, they are specific to PrincipalFolder, IMHO. I think you need: - custom authenticator plugin, that authenticates against RDB and has a dictionary as cache: key = login, value = password; - custom foundprinciplefactory, that generates Principal objects from RDB data, again using a simple key=login,value=Principal dictionary as cache; - eventually a custom credentials plugin, that for your point 3.
(..) So I would very, very much suggest to dig into PAU first and fix those shortcomings before porting it to Plone/Zope2.
Exactly what I am doing :) Thank you very much for your feedback. florian
Am Mittwoch, 16. Juli 2008 05:48 schrieb Florian Friesdorf:
On Mon, Jul 14, 2008 at 09:50:25AM +0200, Hermann Himmelbauer wrote:
(..) 1) No way to pass PAU-related information to form-code: In PAU, the (..) 2) Lack of documentation: The entities "Principal, InternalPrincipal, PrincipalInfo" are very confusing to a newbie, I still don't get the "big picture".
InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects.
Ok, this is how I see it, too. But let me describe my understanding more specific: I see it that way that applications with authentication will normally have something like a "user" object, which stores all related authentication/user information. This user object may reside in a RDB, a text file, or, as here, in a PrincipalFolder (as an InternalPrincipal). If I understand it right, a Principal is an entity that is the result of an authentication process and holds all needed information for authorization. However, it is not designed to store user specific information, e.g. login names, user names and the like. And PrincipalInfo is somehow a specific aggregation of user data, which can be used throughout the application. This object may have to be inherited to an extended MyPrincipalInfo object, as many applications may need extra info from this object. So, both the Principal and PrincipalInfo objects have to be created out of the user object, it is not possible to create a Principal out of a PrincipalInfo and reverse. Throughout my application, I have the following scenarios: - I need to display some user data (e.g. in a "logged in" viewlet): I'd use PrincipalInfo. - I need to check for authorization somewhere in my application: I'd use the Principal. - I need to administer the user, e.g. change password etc.: I'd use the user object (InternalPrincipal) for that. - ??? In my application, all I have is the principal (request.principal). So I need a viable way to retrieve PrincipalInfo and User/internalPrincipal objects. How would I do that? - user object: There seems to be no zope3 support for that yet - so it seems I have to do this manually (some getUser(login) function, get the login from request.principal.id[lenAUTH_PREFIX):], not very pretty, though.). - PrincipalInfo: Don't really know - perhaps by somehow getting the PAU object and iterating over the authentication modules, calling some getPrincipalInfo method? I personally would favour some adapters, e.g.: InternalPrincipal = IInternalPrincipal(request) PrincipalInfo = IPrincipalInfo(request) The current documentation leaves many of the above points open, or at least, did not describe them in a way so that I could understand them.
3) Lack of plugins: No plugin for URL-rewriting, e.g. cookie-less browsers (retrieving auth-information from URL) etc.
I don't know about URL-rewriting, but you should be easily able to write your own credentials plugin to extract whatever you like from a request object.
Sure it's possible, that's what I did. But it was quite complicated and I had to dig very deep into Zope3 code to do that. This is definitely no option for a Zope developer who needs to quickly set up a cookie-less application.
How excactly should I cache user data so that a single browser request does not lead to multiple RDB queries? And where in the big picture is the "User" entity? (It's probably the InternalPrincipal object, I assume)...
You don't need InternalPrincipal objects, they are specific to PrincipalFolder, IMHO.
Well, yes and no - I need some user entity (which is located in the RDB), which somehow resembles the InternalPrincipal object.
I think you need: - custom authenticator plugin, that authenticates against RDB and has a dictionary as cache: key = login, value = password; - custom foundprinciplefactory, that generates Principal objects from RDB data, again using a simple key=login,value=Principal dictionary as cache; - eventually a custom credentials plugin, that for your point 3.
That's basically what I did. However, I did not yet implement caching, as some things are not yet solved: - What if the user changes his password? How would the cache update his data? - What if a user is deleted? So, it seems there needs to be some method that flushes the cache (e.g. if user data changes). Maybe it makes sense to create an extra UserCache utility that provides such methods. This should be very well laid out before implementing, I think. Currently, every simple HTTP request leads to 3 select statements on my user table (due to authentication, prinipalInfo creation and the like). So, this is something that needs to be solved by caching.
So I would very, very much suggest to dig into PAU first and fix those shortcomings before porting it to Plone/Zope2.
Exactly what I am doing :)
That's great! If you have time, please don't forget scenarios, where user data is stored outside Zope3 (e.g. RDB). I would very much appreciate, if Zope3 has some built in support for that. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Wed, Jul 16, 2008 at 10:20:58AM +0200, Hermann Himmelbauer wrote:
Am Mittwoch, 16. Juli 2008 05:48 schrieb Florian Friesdorf:
InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects.
Ok, this is how I see it, too. But let me describe my understanding more specific:
I see it that way that applications with authentication will normally have something like a "user" object, which stores all related authentication/user information. This user object may reside in a RDB, a text file, or, as here, in a PrincipalFolder (as an InternalPrincipal).
I would put the "object" in quotation, too, as for example in RDB it isnt an object at all, but simply authentication data + properties and, yes, this corresponds to InternalPrincipal.
If I understand it right, a Principal is an entity that is the result of an authentication process and holds all needed information for authorization. However, it is not designed to store user specific information, e.g. login names, user names and the like.
And PrincipalInfo is somehow a specific aggregation of user data, which can be used throughout the application. This object may have to be inherited to an extended MyPrincipalInfo object, as many applications may need extra info from this object.
So, both the Principal and PrincipalInfo objects have to be created out of the user object, it is not possible to create a Principal out of a PrincipalInfo and reverse.
I think you are wrong here: zope.app.authentication.authentication.PluggableAuthentication.authenticate is the place to look at. 1. a PrincipalInfo object is got by calling authenticateCredentials from an authplugin 2. this is handed to an AuthenticatedPrincipalFactory, which returns a Principal object So, PrincipalInfo is internal to PAU and as far as I figured does not leave it. Objects that leave PAU are those created by AuthenticatedPrincipalFactories, for authentication, and by FoundPrincipalFactories, for searches - In case of PrincipalFolder that is Principal objects in both cases.
Throughout my application, I have the following scenarios:
- I need to display some user data (e.g. in a "logged in" viewlet): I'd use PrincipalInfo.
I would use the principal object
- I need to check for authorization somewhere in my application: I'd use the Principal.
yes
- I need to administer the user, e.g. change password etc.: I'd use the user object (InternalPrincipal) for that.
I would again use the principal object, which transparently performs the changes wherever they are necessary, i.e all properties of the user are available from the Principal object and changes to them will happen on their actual source.
- ???
In my application, all I have is the principal (request.principal). So I need a viable way to retrieve PrincipalInfo and User/internalPrincipal objects.
How would I do that?
principal is all you need, if it does not carry what you want, you can subscribe to FoundPrincipalCreated and AuthenticatedPrincipalCreated events and stuff on it whatever you need.
- user object: There seems to be no zope3 support for that yet - so it seems I have to do this manually (some getUser(login) function, get the login from request.principal.id[lenAUTH_PREFIX):], not very pretty, though.).
principal is the user object
- PrincipalInfo: Don't really know - perhaps by somehow getting the PAU object and iterating over the authentication modules, calling some getPrincipalInfo method?
I personally would favour some adapters, e.g.:
InternalPrincipal = IInternalPrincipal(request) PrincipalInfo = IPrincipalInfo(request)
In case you store your userdata in RDB, you do not need InternalPrincipal at all. I currently see to options: 1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin would need to return PrincipalInfo objects. Further, you write an event handler that listens for FoundPrincipalCreated and AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto the Principal object, which was created by one of the factories. Those properties can be real python properties with get,set,del methods, which you can use to get,set,del the actual propety values wherever they may come from, e.g. an RDB. 2. you could further write your own factories and return whatever object you would like to represent your user in case of searches and in case of authentication. I think option1 is optimal for your use case, based on what you described so far.
The current documentation leaves many of the above points open, or at least, did not describe them in a way so that I could understand them.
Read the README.txt, look at the doctest in authentication.py and principalfolder.py and look at the code itself - it is very clean and to the point.
Sure it's possible, that's what I did. But it was quite complicated and I had to dig very deep into Zope3 code to do that. This is definitely no option for a Zope developer who needs to quickly set up a cookie-less application.
Did you make your cookie-less credentials plugin available somewhere?
How excactly should I cache user data so that a single browser request does not lead to multiple RDB queries? And where in the big picture is the "User" entity? (It's probably the InternalPrincipal object, I assume)...
You don't need InternalPrincipal objects, they are specific to PrincipalFolder, IMHO.
Well, yes and no - I need some user entity (which is located in the RDB), which somehow resembles the InternalPrincipal object.
see above
I think you need: - custom authenticator plugin, that authenticates against RDB and has a dictionary as cache: key = login, value = password; - custom foundprinciplefactory, that generates Principal objects from RDB data, again using a simple key=login,value=Principal dictionary as cache; - eventually a custom credentials plugin, that for your point 3.
That's basically what I did. However, I did not yet implement caching, as some things are not yet solved:
- What if the user changes his password? How would the cache update his data?
make the cache available as an utility, the factories query the utility and the principal objects (see above), update the cache upon change.
- What if a user is deleted?
remove the user from the cache But honestly, I am a cache novice, so there might be way better approaches...
So, it seems there needs to be some method that flushes the cache (e.g. if user data changes). Maybe it makes sense to create an extra UserCache utility that provides such methods.
I agree that maybe it makes sense (see above)
This should be very well laid out before implementing, I think.
Currently, every simple HTTP request leads to 3 select statements on my user table (due to authentication, prinipalInfo creation and the like). So, this is something that needs to be solved by caching.
That's not nice. You could: 1. your custom authplugin.authenticateCredentials, checks the credentials and if positive places your custom Principal object into the cache utility and returns just the login name as info, i.e. not PrincipalInfo. 2. your custom AuthenticatedPrincipalFactory receives the login name, retrieves the principal object and returns it 3. your FoundPrincipalFactory does the same. Changing user properties is done through your custom principal object. For adding you need a special control panel, that adds the user in the RDB. For deleteing you need a special control panel, that deletes the user in the RDB and from the cache utility.
So I would very, very much suggest to dig into PAU first and fix those shortcomings before porting it to Plone/Zope2.
Exactly what I am doing :)
That's great! If you have time, please don't forget scenarios, where user data is stored outside Zope3 (e.g. RDB). I would very much appreciate, if Zope3 has some built in support for that.
Zope3 currently with PrincipalFolder does support this already. All you need is to listen to the corresponding events (see above). florian PS: Thank you very much for this conversation, it made things a lot clearer to me and will help me with my project. As I am new to the subject, too, it'll be great if someone being really familiar with PAU could shortly give an opinion of whether I got things right...
Am Freitag, 18. Juli 2008 03:55 schrieb Florian Friesdorf:
On Wed, Jul 16, 2008 at 10:20:58AM +0200, Hermann Himmelbauer wrote:
Am Mittwoch, 16. Juli 2008 05:48 schrieb Florian Friesdorf:
InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects.
Ok, this is how I see it, too. But let me describe my understanding more specific:
I see it that way that applications with authentication will normally have something like a "user" object, which stores all related authentication/user information. This user object may reside in a RDB, a text file, or, as here, in a PrincipalFolder (as an InternalPrincipal).
I would put the "object" in quotation, too, as for example in RDB it isnt an object at all, but simply authentication data + properties and, yes, this corresponds to InternalPrincipal.
Yes, that's o.k. In my specific application, I use an ORM, thus table rows are mapped to objects -> "user objects".
If I understand it right, a Principal is an entity that is the result of an authentication process and holds all needed information for authorization. However, it is not designed to store user specific information, e.g. login names, user names and the like.
And PrincipalInfo is somehow a specific aggregation of user data, which can be used throughout the application. This object may have to be inherited to an extended MyPrincipalInfo object, as many applications may need extra info from this object.
So, both the Principal and PrincipalInfo objects have to be created out of the user object, it is not possible to create a Principal out of a PrincipalInfo and reverse.
I think you are wrong here:
Maybe I was, I mixed some things up, it seems.
zope.app.authentication.authentication.PluggableAuthentication.authenticate is the place to look at. 1. a PrincipalInfo object is got by calling authenticateCredentials from an authplugin
Yes, true. For that reason, my AuthenticatorPlugin overwrites the authenticateCredentials method and retrieves the internal principal (=my user object), builds an appropriate PrincipalInfo object and returns that.
2. this is handed to an AuthenticatedPrincipalFactory, which returns a Principal object
Right. so I was wrong above: The Principal object is built out of the PrincipalInfo object. However, that's exactly the problem: The only data I have to create the Principal, is the PrincipalInfo object. Thus I lose any extra user information. So, in order to transport needed information from the user -> Principal, I have two options: 1) Stuff out PrincipalInfo with all needed data that my Principal needs 2) In the AuthenticatedPrincipalFactory I would query for my internal user object (InternalPrincipal) and transfer all needed data to the Principal from there. In my application, I chose (1) for performance reasons, although, I have to admit, is quite complicated, as I have to create a customer PrincipalInfo class etc., moreover, the IPrincipalInfo class states: class IPrincipalInfo(zope.interface.Interface): """Minimal information about a principal.""" For variant (1) it has to hold a lot more information, so it contradicts the meaning of this class.
So, PrincipalInfo is internal to PAU and as far as I figured does not leave it. Objects that leave PAU are those created by AuthenticatedPrincipalFactories, for authentication, and by FoundPrincipalFactories, for searches - In case of PrincipalFolder that is Principal objects in both cases.
Yes, that's true.
- I need to administer the user, e.g. change password etc.: I'd use the user object (InternalPrincipal) for that.
I would again use the principal object, which transparently performs the changes wherever they are necessary, i.e all properties of the user are available from the Principal object and changes to them will happen on their actual source.
Hmmm, interesting.
- user object: There seems to be no zope3 support for that yet - so it seems I have to do this manually (some getUser(login) function, get the login from request.principal.id[lenAUTH_PREFIX):], not very pretty, though.).
principal is the user object
Ok, it seems that the principal is really the representation of my user object and may hold anything I need.
In case you store your userdata in RDB, you do not need InternalPrincipal at all. I currently see to options:
1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin would need to return PrincipalInfo objects. Further, you write an event handler that listens for FoundPrincipalCreated and AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto the Principal object, which was created by one of the factories. Those properties can be real python properties with get,set,del methods, which you can use to get,set,del the actual propety values wherever they may come from, e.g. an RDB.
Hmmm, interesting approach. But would that also mean that the principal may hold also sensitive information, e.g. the password? Are there any security concerns about doing so?
Sure it's possible, that's what I did. But it was quite complicated and I had to dig very deep into Zope3 code to do that. This is definitely no option for a Zope developer who needs to quickly set up a cookie-less application.
Did you make your cookie-less credentials plugin available somewhere?
I can send you my code, if you like. However, it's somehow a little bit ugly due to some Zope3 internals I could not understand/solve.
That's basically what I did. However, I did not yet implement caching, as some things are not yet solved:
- What if the user changes his password? How would the cache update his data?
make the cache available as an utility, the factories query the utility and the principal objects (see above), update the cache upon change.
- What if a user is deleted?
remove the user from the cache
Yes, these are somehow also my ideas.
Currently, every simple HTTP request leads to 3 select statements on my user table (due to authentication, prinipalInfo creation and the like). So, this is something that needs to be solved by caching.
That's not nice. You could: 1. your custom authplugin.authenticateCredentials, checks the credentials and if positive places your custom Principal object into the cache utility and returns just the login name as info, i.e. not PrincipalInfo. 2. your custom AuthenticatedPrincipalFactory receives the login name, retrieves the principal object and returns it 3. your FoundPrincipalFactory does the same.
Yes, that would imply setting up some sort of caching.
So I would very, very much suggest to dig into PAU first and fix those shortcomings before porting it to Plone/Zope2.
Exactly what I am doing :)
That's great! If you have time, please don't forget scenarios, where user data is stored outside Zope3 (e.g. RDB). I would very much appreciate, if Zope3 has some built in support for that.
Zope3 currently with PrincipalFolder does support this already. All you need is to listen to the corresponding events (see above).
What I moreover think about is why not to pull the PAU stuff out of zope.app and create a package such as "zope.authentication". This may be more generic. To sum it up, during authentication, user information is needed four times: 1) In customization of authplugin.authenticateCredentials (to check for correct login/pass) 2) In the Authenticated PrincipalFactory, or, better, in a subscriber to that event which stuffs out the principal with all needed data 3) For getPrincipal() calls (Two in my case for every request, no clue why and where they are called). In case of a not-so-fast access to user data (such as in my case, where RDB queries have to be issued), caching can heavily improve the performance. So, it seems, a good idea would be to create some caching-related package that integrates nicely with the PAU.
PS: Thank you very much for this conversation, it made things a lot clearer to me and will help me with my project. As I am new to the subject, too, it'll be great if someone being really familiar with PAU could shortly give an opinion of whether I got things right...
Yes, many thanks to you, too. And I would also be very interested in hearing comments about this from others. BTW. I also send this to Roger Ineichen, as he also suffered from shortcomings of zope.app.authentication and built his own "z3c.authentication", which is also an interesting read. (Although I could not yet find time to play around with it). Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Fri, Jul 18, 2008 at 05:00:50PM +0200, Hermann Himmelbauer wrote:
Am Freitag, 18. Juli 2008 03:55 schrieb Florian Friesdorf: (..)
In case you store your userdata in RDB, you do not need InternalPrincipal at all. I currently see to options:
1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin would need to return PrincipalInfo objects. Further, you write an event handler that listens for FoundPrincipalCreated and AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto the Principal object, which was created by one of the factories. Those properties can be real python properties with get,set,del methods, which you can use to get,set,del the actual propety values wherever they may come from, e.g. an RDB.
Hmmm, interesting approach. But would that also mean that the principal may hold also sensitive information, e.g. the password? Are there any security concerns about doing so?
You won't need it for authentication, so it would be sufficient to support setting the password through the principal object, which then would transparently work on the RDB.
Sure it's possible, that's what I did. But it was quite complicated and I had to dig very deep into Zope3 code to do that. This is definitely no option for a Zope developer who needs to quickly set up a cookie-less application.
Did you make your cookie-less credentials plugin available somewhere?
I can send you my code, if you like. However, it's somehow a little bit ugly due to some Zope3 internals I could not understand/solve.
Would be nice to have it, though I don't know whether I'll have the time for a closer look and eventually help you with Z3 stuff, at least until Aug 18th (end of GSOC).
What I moreover think about is why not to pull the PAU stuff out of zope.app and create a package such as "zope.authentication". This may be more generic.
I think most of the code assumes running inside the zope application server using ZODB (Persistent), so it won't be useful outside.
To sum it up, during authentication, user information is needed four times:
1) In customization of authplugin.authenticateCredentials (to check for correct login/pass) 2) In the Authenticated PrincipalFactory, or, better, in a subscriber to that event which stuffs out the principal with all needed data 3) For getPrincipal() calls (Two in my case for every request, no clue why and where they are called).
In case of a not-so-fast access to user data (such as in my case, where RDB queries have to be issued), caching can heavily improve the performance.
So, it seems, a good idea would be to create some caching-related package that integrates nicely with the PAU.
I am not sure, whether this can be generalized or should be specific to where the data is coming from.
Yes, many thanks to you, too. And I would also be very interested in hearing comments about this from others.
It seems there aren't too many people using PAU...
BTW. I also send this to Roger Ineichen, as he also suffered from shortcomings of zope.app.authentication and built his own "z3c.authentication", which is also an interesting read. (Although I could not yet find time to play around with it).
Interesting, will have a look. florian
participants (10)
-
Andreas Jung -
Florian Friesdorf -
Hermann Himmelbauer -
Jens Vagelpohl -
Mark Hammond -
Martin Aspeli -
Philipp von Weitershausen -
Sidnei da Silva -
Tres Seaver -
Wichert Akkerman