FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=14341&edit=1

ID: 14341
Comment by: bcooksley
Reported By: bcooksley at kde dot org
Summary: Complex updates fail
Status: Wont fix
Type: Bug
Package: Net_LDAP2
Operating System: Linux/Fedora 9
Package Version: 2.0.0RC3
PHP Version: 5.2.6
Assigned To: beni
New Comment:

I have started to look into this issue as our LDAP directory has strict
permissions, preventing the deletion workaround from working.

This issue is interlinked with a number of other issues:
- If you try to delete a non-retrieved attribute when using LDAPv3 it
will fail
- If you try to add a value to a non-retrieved attribute then all other
values will be erased

To fix both this issue and the two above, I intend to make it
automatically retrieve the entry if the attribute being changed is *not*
loaded.


Previous Comments:
------------------------------------------------------------------------

[2008-10-16 07:49:41] zoeloelip

I haven't got the time to look at this because of my new job. Deleting
is just to dangerous.

------------------------------------------------------------------------

[2008-10-16 05:32:12] beni

Unfortunately this is not easy to fix due to Net_LDAP's architecture.
Net_LDAP was meant to modify parts of entries without the need to know
the entire entry in the server.

I tried to rewrite update() so it does everything with just one
LDAP-query but this is not easily possible.
Maybe you will find a good solution to this, but a good workaround is to
remove the entry and add it with the new objectclass. This way, you also
can add structual objectclass changes.

I will document that and close the bug.

------------------------------------------------------------------------

[2008-08-26 11:09:13] beni

Something new on that topic?
Did you have time to research some patches?

------------------------------------------------------------------------

[2008-07-15 09:47:16] zoeloelip

I think the only way to go is 1, because when schemachecks are on (which
seems the default on rhel 5) you get errors from ldap if you don't do
all changes at once. I got the use of ldap_modify from phpldapadmin.

I'll try to create a patch in the next few days but I won't have a lot
of time. I'll keep you posted.

------------------------------------------------------------------------

[2008-07-15 09:32:51] beni

I would favor option 1 if it works safely in every situation.
would you like to try to rewrite that part of update()?

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://pear.php.net/bugs/bug.php?id=14341

Search Discussions

  • Bcooksley at Dec 15, 2011 at 2:04 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Comment by: bcooksley@kde.org
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Wont fix
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    I have done some research into the background of this problem, and it
    turns out that the cause of this issue lies directly with the php-ldap
    api itself.

    http://www.mail-archive.com/internals@lists.php.net/msg11100.html

    Apparently php's ldap_modify function is actually ldap_modify_replace in
    OpenLDAP's API for unknown reasons. Would it be better to get this fixed
    in php-ldap or to implement a mild hack and just retrieve the full entry
    and build the needed changes array from that?


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 00:21:52] bcooksley

    I have started to look into this issue as our LDAP directory has strict
    permissions, preventing the deletion workaround from working.

    This issue is interlinked with a number of other issues:
    - If you try to delete a non-retrieved attribute when using LDAPv3 it
    will fail
    - If you try to add a value to a non-retrieved attribute then all other
    values will be erased

    To fix both this issue and the two above, I intend to make it
    automatically retrieve the entry if the attribute being changed is *not*
    loaded.

    ------------------------------------------------------------------------

    [2008-10-16 07:49:41] zoeloelip

    I haven't got the time to look at this because of my new job. Deleting
    is just to dangerous.

    ------------------------------------------------------------------------

    [2008-10-16 05:32:12] beni

    Unfortunately this is not easy to fix due to Net_LDAP's architecture.
    Net_LDAP was meant to modify parts of entries without the need to know
    the entire entry in the server.

    I tried to rewrite update() so it does everything with just one
    LDAP-query but this is not easily possible.
    Maybe you will find a good solution to this, but a good workaround is to
    remove the entry and add it with the new objectclass. This way, you also
    can add structual objectclass changes.

    I will document that and close the bug.

    ------------------------------------------------------------------------

    [2008-08-26 11:09:13] beni

    Something new on that topic?
    Did you have time to research some patches?

    ------------------------------------------------------------------------

    [2008-07-15 09:47:16] zoeloelip

    I think the only way to go is 1, because when schemachecks are on (which
    seems the default on rhel 5) you get errors from ldap if you don't do
    all changes at once. I got the use of ldap_modify from phpldapadmin.

    I'll try to create a patch in the next few days but I won't have a lot
    of time. I'll keep you posted.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Bcooksley at Dec 15, 2011 at 4:41 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Comment by: bcooksley@kde.org
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Wont fix
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    I've attached a patch which does two things:

    1) Moves it to using a single ldap_modify() command for all
    modifications
    2) Disables the deletion of the old RDN attribute

    I needed both as otherwise my changes were rejected with
    LDAP_OBJECT_CLASS_VIOLATION (as the old RDN is a MUST attribute of a
    Object Class) when attempting to perform moves.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 04:27:03] bcooksley

    Added #patch bug:14341;patch:use-ldap-modify-once;revision:1323923223;.

    ------------------------------------------------------------------------

    [2011-12-15 03:44:28] bcooksley

    Added #patch
    bug:14341;patch:change-entry-use-ldap-modify-once;revision:1323920668;.

    ------------------------------------------------------------------------

    [2011-12-15 03:04:40] bcooksley

    I have done some research into the background of this problem, and it
    turns out that the cause of this issue lies directly with the php-ldap
    api itself.

    http://www.mail-archive.com/internals@lists.php.net/msg11100.html

    Apparently php's ldap_modify function is actually ldap_modify_replace in
    OpenLDAP's API for unknown reasons. Would it be better to get this fixed
    in php-ldap or to implement a mild hack and just retrieve the full entry
    and build the needed changes array from that?

    ------------------------------------------------------------------------

    [2011-12-15 00:21:52] bcooksley

    I have started to look into this issue as our LDAP directory has strict
    permissions, preventing the deletion workaround from working.

    This issue is interlinked with a number of other issues:
    - If you try to delete a non-retrieved attribute when using LDAPv3 it
    will fail
    - If you try to add a value to a non-retrieved attribute then all other
    values will be erased

    To fix both this issue and the two above, I intend to make it
    automatically retrieve the entry if the attribute being changed is *not*
    loaded.

    ------------------------------------------------------------------------

    [2008-10-16 07:49:41] zoeloelip

    I haven't got the time to look at this because of my new job. Deleting
    is just to dangerous.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Beni at Dec 15, 2011 at 9:41 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Updated by: beni@php.net
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    -Status: Wont fix
    +Status: Open
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    -Status: Wont fix
    +Status: Open
    The problem with retrievability is, that some attributes ma ynever be
    retrievable at all, they are only replaceable (like password fields).
    There should be some mechanism that retrieving the attribute is only
    tried once, and also an option to disable that feature alltogether since
    it slows down the library considerably under some circumstances.

    I reopened that bug for further discussion.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 05:41:04] bcooksley

    I've attached a patch which does two things:

    1) Moves it to using a single ldap_modify() command for all
    modifications
    2) Disables the deletion of the old RDN attribute

    I needed both as otherwise my changes were rejected with
    LDAP_OBJECT_CLASS_VIOLATION (as the old RDN is a MUST attribute of a
    Object Class) when attempting to perform moves.

    ------------------------------------------------------------------------

    [2011-12-15 04:27:03] bcooksley

    Added #patch bug:14341;patch:use-ldap-modify-once;revision:1323923223;.

    ------------------------------------------------------------------------

    [2011-12-15 03:44:28] bcooksley

    Added #patch
    bug:14341;patch:change-entry-use-ldap-modify-once;revision:1323920668;.

    ------------------------------------------------------------------------

    [2011-12-15 03:04:40] bcooksley

    I have done some research into the background of this problem, and it
    turns out that the cause of this issue lies directly with the php-ldap
    api itself.

    http://www.mail-archive.com/internals@lists.php.net/msg11100.html

    Apparently php's ldap_modify function is actually ldap_modify_replace in
    OpenLDAP's API for unknown reasons. Would it be better to get this fixed
    in php-ldap or to implement a mild hack and just retrieve the full entry
    and build the needed changes array from that?

    ------------------------------------------------------------------------

    [2011-12-15 00:21:52] bcooksley

    I have started to look into this issue as our LDAP directory has strict
    permissions, preventing the deletion workaround from working.

    This issue is interlinked with a number of other issues:
    - If you try to delete a non-retrieved attribute when using LDAPv3 it
    will fail
    - If you try to add a value to a non-retrieved attribute then all other
    values will be erased

    To fix both this issue and the two above, I intend to make it
    automatically retrieve the entry if the attribute being changed is *not*
    loaded.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Bcooksley at Dec 15, 2011 at 9:47 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Comment by: bcooksley@kde.org
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    Yes, I considered that issue. I am still working on the automatic
    retrieval - I intend to use a private boolean which informs it if it
    needs to retrieve the full set or not. So the retrieval should only
    happen once.

    Would a property held by the server to control if autoretrieval should
    be attempted be the best place to put the "global" switch to disable
    this behaviour?

    The patch I have already attached should work for the replace case,
    except for Microsoft AD (which I hear requires a simultaneous delete/add
    which PHP cannot do due to weaknesses in it's LDAP api)


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 10:41:21] beni

    -Status: Wont fix
    +Status: Open
    The problem with retrievability is, that some attributes ma ynever be
    retrievable at all, they are only replaceable (like password fields).
    There should be some mechanism that retrieving the attribute is only
    tried once, and also an option to disable that feature alltogether since
    it slows down the library considerably under some circumstances.

    I reopened that bug for further discussion.

    ------------------------------------------------------------------------

    [2011-12-15 05:41:04] bcooksley

    I've attached a patch which does two things:

    1) Moves it to using a single ldap_modify() command for all
    modifications
    2) Disables the deletion of the old RDN attribute

    I needed both as otherwise my changes were rejected with
    LDAP_OBJECT_CLASS_VIOLATION (as the old RDN is a MUST attribute of a
    Object Class) when attempting to perform moves.

    ------------------------------------------------------------------------

    [2011-12-15 04:27:03] bcooksley

    Added #patch bug:14341;patch:use-ldap-modify-once;revision:1323923223;.

    ------------------------------------------------------------------------

    [2011-12-15 03:44:28] bcooksley

    Added #patch
    bug:14341;patch:change-entry-use-ldap-modify-once;revision:1323920668;.

    ------------------------------------------------------------------------

    [2011-12-15 03:04:40] bcooksley

    I have done some research into the background of this problem, and it
    turns out that the cause of this issue lies directly with the php-ldap
    api itself.

    http://www.mail-archive.com/internals@lists.php.net/msg11100.html

    Apparently php's ldap_modify function is actually ldap_modify_replace in
    OpenLDAP's API for unknown reasons. Would it be better to get this fixed
    in php-ldap or to implement a mild hack and just retrieve the full entry
    and build the needed changes array from that?

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Beni at Dec 15, 2011 at 9:55 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Updated by: beni@php.net
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    Well im not aware of any information on a standard LDAP server that lets
    us decide on the autoretrieval.
    Retrievability is part of the servers ACL and this is usually not
    disclosured to the clients for security reasons.

    The only place where i would put that would be Net_LDAPs config.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 10:47:03] bcooksley

    Yes, I considered that issue. I am still working on the automatic
    retrieval - I intend to use a private boolean which informs it if it
    needs to retrieve the full set or not. So the retrieval should only
    happen once.

    Would a property held by the server to control if autoretrieval should
    be attempted be the best place to put the "global" switch to disable
    this behaviour?

    The patch I have already attached should work for the replace case,
    except for Microsoft AD (which I hear requires a simultaneous delete/add
    which PHP cannot do due to weaknesses in it's LDAP api)

    ------------------------------------------------------------------------

    [2011-12-15 10:41:21] beni

    -Status: Wont fix
    +Status: Open
    The problem with retrievability is, that some attributes ma ynever be
    retrievable at all, they are only replaceable (like password fields).
    There should be some mechanism that retrieving the attribute is only
    tried once, and also an option to disable that feature alltogether since
    it slows down the library considerably under some circumstances.

    I reopened that bug for further discussion.

    ------------------------------------------------------------------------

    [2011-12-15 05:41:04] bcooksley

    I've attached a patch which does two things:

    1) Moves it to using a single ldap_modify() command for all
    modifications
    2) Disables the deletion of the old RDN attribute

    I needed both as otherwise my changes were rejected with
    LDAP_OBJECT_CLASS_VIOLATION (as the old RDN is a MUST attribute of a
    Object Class) when attempting to perform moves.

    ------------------------------------------------------------------------

    [2011-12-15 04:27:03] bcooksley

    Added #patch bug:14341;patch:use-ldap-modify-once;revision:1323923223;.

    ------------------------------------------------------------------------

    [2011-12-15 03:44:28] bcooksley

    Added #patch
    bug:14341;patch:change-entry-use-ldap-modify-once;revision:1323920668;.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Beni at Dec 15, 2011 at 10:20 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Updated by: beni@php.net
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    Another thing to consider is, that not all entrys represent actual ldap
    entries.
    Sometimes people build up dummy entries to just carry out a specific
    operation (like replacing passwords or adding values regardless of the
    ldap state).
    So the attribute retrieval must be a global default option, but also may
    be overriden at the entry-object level to be able to turn it off for
    each entry individually. A newly created entry would pull the config
    from the ldap object when it becomes necessary (e.g. it gets linked to
    the ldap object)

    By standard i would turn off this autofetch feature.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 10:55:33] beni

    Well im not aware of any information on a standard LDAP server that lets
    us decide on the autoretrieval.
    Retrievability is part of the servers ACL and this is usually not
    disclosured to the clients for security reasons.

    The only place where i would put that would be Net_LDAPs config.

    ------------------------------------------------------------------------

    [2011-12-15 10:47:03] bcooksley

    Yes, I considered that issue. I am still working on the automatic
    retrieval - I intend to use a private boolean which informs it if it
    needs to retrieve the full set or not. So the retrieval should only
    happen once.

    Would a property held by the server to control if autoretrieval should
    be attempted be the best place to put the "global" switch to disable
    this behaviour?

    The patch I have already attached should work for the replace case,
    except for Microsoft AD (which I hear requires a simultaneous delete/add
    which PHP cannot do due to weaknesses in it's LDAP api)

    ------------------------------------------------------------------------

    [2011-12-15 10:41:21] beni

    -Status: Wont fix
    +Status: Open
    The problem with retrievability is, that some attributes ma ynever be
    retrievable at all, they are only replaceable (like password fields).
    There should be some mechanism that retrieving the attribute is only
    tried once, and also an option to disable that feature alltogether since
    it slows down the library considerably under some circumstances.

    I reopened that bug for further discussion.

    ------------------------------------------------------------------------

    [2011-12-15 05:41:04] bcooksley

    I've attached a patch which does two things:

    1) Moves it to using a single ldap_modify() command for all
    modifications
    2) Disables the deletion of the old RDN attribute

    I needed both as otherwise my changes were rejected with
    LDAP_OBJECT_CLASS_VIOLATION (as the old RDN is a MUST attribute of a
    Object Class) when attempting to perform moves.

    ------------------------------------------------------------------------

    [2011-12-15 04:27:03] bcooksley

    Added #patch bug:14341;patch:use-ldap-modify-once;revision:1323923223;.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Bcooksley at Dec 15, 2011 at 11:21 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Comment by: bcooksley@kde.org
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    Property held by the server = Net::LDAP2 class configuration.

    Auto-retrieval would of course only be enabled if permitted by the
    Net::LDAP2 configuration - and it has a LDAP Entry it is representing.

    Can you please examine the patch I have uploaded at the moment? It
    alters the update() function to use ldap_modify() - building the list of
    changes using a freshly retrieved copy of the entry which has all
    attributes requested.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 11:20:38] beni

    Another thing to consider is, that not all entrys represent actual ldap
    entries.
    Sometimes people build up dummy entries to just carry out a specific
    operation (like replacing passwords or adding values regardless of the
    ldap state).
    So the attribute retrieval must be a global default option, but also may
    be overriden at the entry-object level to be able to turn it off for
    each entry individually. A newly created entry would pull the config
    from the ldap object when it becomes necessary (e.g. it gets linked to
    the ldap object)

    By standard i would turn off this autofetch feature.

    ------------------------------------------------------------------------

    [2011-12-15 10:55:33] beni

    Well im not aware of any information on a standard LDAP server that lets
    us decide on the autoretrieval.
    Retrievability is part of the servers ACL and this is usually not
    disclosured to the clients for security reasons.

    The only place where i would put that would be Net_LDAPs config.

    ------------------------------------------------------------------------

    [2011-12-15 10:47:03] bcooksley

    Yes, I considered that issue. I am still working on the automatic
    retrieval - I intend to use a private boolean which informs it if it
    needs to retrieve the full set or not. So the retrieval should only
    happen once.

    Would a property held by the server to control if autoretrieval should
    be attempted be the best place to put the "global" switch to disable
    this behaviour?

    The patch I have already attached should work for the replace case,
    except for Microsoft AD (which I hear requires a simultaneous delete/add
    which PHP cannot do due to weaknesses in it's LDAP api)

    ------------------------------------------------------------------------

    [2011-12-15 10:41:21] beni

    -Status: Wont fix
    +Status: Open
    The problem with retrievability is, that some attributes ma ynever be
    retrievable at all, they are only replaceable (like password fields).
    There should be some mechanism that retrieving the attribute is only
    tried once, and also an option to disable that feature alltogether since
    it slows down the library considerably under some circumstances.

    I reopened that bug for further discussion.

    ------------------------------------------------------------------------

    [2011-12-15 05:41:04] bcooksley

    I've attached a patch which does two things:

    1) Moves it to using a single ldap_modify() command for all
    modifications
    2) Disables the deletion of the old RDN attribute

    I needed both as otherwise my changes were rejected with
    LDAP_OBJECT_CLASS_VIOLATION (as the old RDN is a MUST attribute of a
    Object Class) when attempting to perform moves.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Beni at Dec 15, 2011 at 12:08 pm
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Updated by: beni@php.net
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    The patch (use-ldap-modify-once) looks good on a first glance.
    Can you confirm the unit tests are running well with it applied?


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 12:21:01] bcooksley

    Property held by the server = Net::LDAP2 class configuration.

    Auto-retrieval would of course only be enabled if permitted by the
    Net::LDAP2 configuration - and it has a LDAP Entry it is representing.

    Can you please examine the patch I have uploaded at the moment? It
    alters the update() function to use ldap_modify() - building the list of
    changes using a freshly retrieved copy of the entry which has all
    attributes requested.

    ------------------------------------------------------------------------

    [2011-12-15 11:20:38] beni

    Another thing to consider is, that not all entrys represent actual ldap
    entries.
    Sometimes people build up dummy entries to just carry out a specific
    operation (like replacing passwords or adding values regardless of the
    ldap state).
    So the attribute retrieval must be a global default option, but also may
    be overriden at the entry-object level to be able to turn it off for
    each entry individually. A newly created entry would pull the config
    from the ldap object when it becomes necessary (e.g. it gets linked to
    the ldap object)

    By standard i would turn off this autofetch feature.

    ------------------------------------------------------------------------

    [2011-12-15 10:55:33] beni

    Well im not aware of any information on a standard LDAP server that lets
    us decide on the autoretrieval.
    Retrievability is part of the servers ACL and this is usually not
    disclosured to the clients for security reasons.

    The only place where i would put that would be Net_LDAPs config.

    ------------------------------------------------------------------------

    [2011-12-15 10:47:03] bcooksley

    Yes, I considered that issue. I am still working on the automatic
    retrieval - I intend to use a private boolean which informs it if it
    needs to retrieve the full set or not. So the retrieval should only
    happen once.

    Would a property held by the server to control if autoretrieval should
    be attempted be the best place to put the "global" switch to disable
    this behaviour?

    The patch I have already attached should work for the replace case,
    except for Microsoft AD (which I hear requires a simultaneous delete/add
    which PHP cannot do due to weaknesses in it's LDAP api)

    ------------------------------------------------------------------------

    [2011-12-15 10:41:21] beni

    -Status: Wont fix
    +Status: Open
    The problem with retrievability is, that some attributes ma ynever be
    retrievable at all, they are only replaceable (like password fields).
    There should be some mechanism that retrieving the attribute is only
    tried once, and also an option to disable that feature alltogether since
    it slows down the library considerably under some circumstances.

    I reopened that bug for further discussion.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Bcooksley at Dec 16, 2011 at 1:23 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Comment by: bcooksley@kde.org
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    As far as I can tell - at least on my system with the unit tests - they
    run the same regardless of the patch being applied or not.

    Results = Tests: 94, Assertions: 406, Failures: 2, Incomplete: 31,
    Skipped: 34
    Failures were in Net_LDAP2_LDIFTest and Net_LDAP2_FilterTest which were
    untouched by my patch.

    Not sure about the 31 incomplete tests though.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-15 13:08:05] beni

    The patch (use-ldap-modify-once) looks good on a first glance.
    Can you confirm the unit tests are running well with it applied?

    ------------------------------------------------------------------------

    [2011-12-15 12:21:01] bcooksley

    Property held by the server = Net::LDAP2 class configuration.

    Auto-retrieval would of course only be enabled if permitted by the
    Net::LDAP2 configuration - and it has a LDAP Entry it is representing.

    Can you please examine the patch I have uploaded at the moment? It
    alters the update() function to use ldap_modify() - building the list of
    changes using a freshly retrieved copy of the entry which has all
    attributes requested.

    ------------------------------------------------------------------------

    [2011-12-15 11:20:38] beni

    Another thing to consider is, that not all entrys represent actual ldap
    entries.
    Sometimes people build up dummy entries to just carry out a specific
    operation (like replacing passwords or adding values regardless of the
    ldap state).
    So the attribute retrieval must be a global default option, but also may
    be overriden at the entry-object level to be able to turn it off for
    each entry individually. A newly created entry would pull the config
    from the ldap object when it becomes necessary (e.g. it gets linked to
    the ldap object)

    By standard i would turn off this autofetch feature.

    ------------------------------------------------------------------------

    [2011-12-15 10:55:33] beni

    Well im not aware of any information on a standard LDAP server that lets
    us decide on the autoretrieval.
    Retrievability is part of the servers ACL and this is usually not
    disclosured to the clients for security reasons.

    The only place where i would put that would be Net_LDAPs config.

    ------------------------------------------------------------------------

    [2011-12-15 10:47:03] bcooksley

    Yes, I considered that issue. I am still working on the automatic
    retrieval - I intend to use a private boolean which informs it if it
    needs to retrieve the full set or not. So the retrieval should only
    happen once.

    Would a property held by the server to control if autoretrieval should
    be attempted be the best place to put the "global" switch to disable
    this behaviour?

    The patch I have already attached should work for the replace case,
    except for Microsoft AD (which I hear requires a simultaneous delete/add
    which PHP cannot do due to weaknesses in it's LDAP api)

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Bcooksley at Dec 23, 2011 at 7:12 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Comment by: bcooksley@kde.org
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    Status: Assigned
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    Beni, what is the status of this being committed?
    Do I need to adjust my test configuration somehow do provide correct
    results?


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-16 02:23:36] bcooksley

    As far as I can tell - at least on my system with the unit tests - they
    run the same regardless of the patch being applied or not.

    Results = Tests: 94, Assertions: 406, Failures: 2, Incomplete: 31,
    Skipped: 34
    Failures were in Net_LDAP2_LDIFTest and Net_LDAP2_FilterTest which were
    untouched by my patch.

    Not sure about the 31 incomplete tests though.

    ------------------------------------------------------------------------

    [2011-12-15 13:08:05] beni

    The patch (use-ldap-modify-once) looks good on a first glance.
    Can you confirm the unit tests are running well with it applied?

    ------------------------------------------------------------------------

    [2011-12-15 12:21:01] bcooksley

    Property held by the server = Net::LDAP2 class configuration.

    Auto-retrieval would of course only be enabled if permitted by the
    Net::LDAP2 configuration - and it has a LDAP Entry it is representing.

    Can you please examine the patch I have uploaded at the moment? It
    alters the update() function to use ldap_modify() - building the list of
    changes using a freshly retrieved copy of the entry which has all
    attributes requested.

    ------------------------------------------------------------------------

    [2011-12-15 11:20:38] beni

    Another thing to consider is, that not all entrys represent actual ldap
    entries.
    Sometimes people build up dummy entries to just carry out a specific
    operation (like replacing passwords or adding values regardless of the
    ldap state).
    So the attribute retrieval must be a global default option, but also may
    be overriden at the entry-object level to be able to turn it off for
    each entry individually. A newly created entry would pull the config
    from the ldap object when it becomes necessary (e.g. it gets linked to
    the ldap object)

    By standard i would turn off this autofetch feature.

    ------------------------------------------------------------------------

    [2011-12-15 10:55:33] beni

    Well im not aware of any information on a standard LDAP server that lets
    us decide on the autoretrieval.
    Retrievability is part of the servers ACL and this is usually not
    disclosured to the clients for security reasons.

    The only place where i would put that would be Net_LDAPs config.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341
  • Beni at Dec 23, 2011 at 8:56 am
    Edit report at https://pear.php.net/bugs/bug.php?id=14341&edit=1

    ID: 14341
    Updated by: beni@php.net
    Reported By: bart at ulyssis dot org
    Summary: Complex updates fail
    -Status: Assigned
    +Status: Verified
    Type: Bug
    Package: Net_LDAP2
    Operating System: Linux/Fedora 9
    Package Version: 2.0.0RC3
    PHP Version: 5.2.6
    Assigned To: beni
    Roadmap Versions:
    New Comment:

    -Status: Assigned
    +Status: Verified
    Hi,
    i don't think that you need to adjust something. The tests look good so
    far, however i didn't had the time to verify and integrate it into the
    trunk.
    Expect the patch to be applied.

    If you have the time, it would be very cool if you could write some unit
    tests for modify.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-12-23 08:13:02] bcooksley

    Beni, what is the status of this being committed?
    Do I need to adjust my test configuration somehow do provide correct
    results?

    ------------------------------------------------------------------------

    [2011-12-16 02:23:36] bcooksley

    As far as I can tell - at least on my system with the unit tests - they
    run the same regardless of the patch being applied or not.

    Results = Tests: 94, Assertions: 406, Failures: 2, Incomplete: 31,
    Skipped: 34
    Failures were in Net_LDAP2_LDIFTest and Net_LDAP2_FilterTest which were
    untouched by my patch.

    Not sure about the 31 incomplete tests though.

    ------------------------------------------------------------------------

    [2011-12-15 13:08:05] beni

    The patch (use-ldap-modify-once) looks good on a first glance.
    Can you confirm the unit tests are running well with it applied?

    ------------------------------------------------------------------------

    [2011-12-15 12:21:01] bcooksley

    Property held by the server = Net::LDAP2 class configuration.

    Auto-retrieval would of course only be enabled if permitted by the
    Net::LDAP2 configuration - and it has a LDAP Entry it is representing.

    Can you please examine the patch I have uploaded at the moment? It
    alters the update() function to use ldap_modify() - building the list of
    changes using a freshly retrieved copy of the entry which has all
    attributes requested.

    ------------------------------------------------------------------------

    [2011-12-15 11:20:38] beni

    Another thing to consider is, that not all entrys represent actual ldap
    entries.
    Sometimes people build up dummy entries to just carry out a specific
    operation (like replacing passwords or adding values regardless of the
    ldap state).
    So the attribute retrieval must be a global default option, but also may
    be overriden at the entry-object level to be able to turn it off for
    each entry individually. A newly created entry would pull the config
    from the ldap object when it becomes necessary (e.g. it gets linked to
    the ldap object)

    By standard i would turn off this autofetch feature.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=14341

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedDec 14, '11 at 11:22p
activeDec 23, '11 at 8:56a
posts12
users3
websitepear.php.net

3 users in discussion

Bcooksley: 6 posts Beni: 5 posts Bcooksley: 1 post

People

Translate

site design / logo © 2022 Grokbase