On Wed, 2013-02-13 at 18:16 +0100, Petr Viktorin wrote:
> On 02/13/2013 05:57 PM, 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.
> >>>
> >>> Simo.
> >>>
> >>
> >> 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
> >> UID/GID/ipaUniqueId, etc).
> >
> > Why are they done after the add ? It seem dangerous.
> 
> This comment from the user-add post-op plugin should explain:
> 
> # Fetch the entry again to update memberof, mep data, etc updated
> # at the end of the transaction.
> 
> Some processing happens in DS plugins, we can't get the data if the 
> object isn't added yet.

Is this data actually needed for the post-op plugins ?

Also what happens if a post-op plugin fails ?

Please don't tell me the framework deletes the user object that would be
really bad.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to