On 02/13/2013 09:57 AM, Simo Sorce wrote:
On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
Our own post-callback assumes the user is already in LDAP, and who
knows what user-supplied callbacks will do. Keep in mind IPA is
plugable; at least for outside plugins' sake (if not our own sanity's)
we should keep the number of code paths to a minimum.
True which is why my proposal is to not use the standard user-add RPC
call, but have a separate one.
This separate call would only call the core business logic to create the
user account add operation, but none of the external plumbing.
Ideally we spit the framework flow like this:
Normal user -> Real user-add --- . . . . . . . . . --- LDAP add
-- common logic --
389ds plugin -> Mock user-add -- . . . . . . . . . --- json reply
custom plugins should be called in the custom logic an operate on the
object before the ADD is attempted.
If we do it this way then most of the code path will be in common which
is what we want, and only the mechanical operation of adding the actual
object to ldap will be different.
There is one missing a few steps. A plugin execution looks like:
Normal user -> Real user-add --- pre-op call(s) --- execute (LPAP add
record) --- post-op call(s) which may do additional add/modify
It is the postop calls that would be the problem. They assume that the
entry has already been written (so, for example, it has a valid
Why are they done after the add ? It seem dangerous.
What happens id the first ldap add succeed and the post op fails ?
Are you talking about 389 plugins? If so, then in 1.3.0 and later, if
you do all of the pre-op/post-op as betxn plugins, then they all take
place in the same transaction, and they all succeed or all fail.
We should exceute the ldap call after the post ops are perfomed imho.
Freeipa-devel mailing list