Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.5
    • Fix Version/s: 2.0.0-M13
    • Component/s: None
    • Labels:
      None

      Description

      I'm developing a custom partition and custom authentication handler to plug into ApacheDS, and need to know the connection details of the client performing the requests. A reason why this might be useful it to be able to log the source of invalid authentication requests.

      The CoreSession object has a getClientAddress() method, however it always returns null. The CoreSession object is accessible from the places where it would be useful (i.e. via the context objects passed into the Partition methods ... and also in the AuthenticationInterceptor.) Upon further investigation it looks like the implementation in DefaultCoreSession is hard-coded to return null.

      It also appears that the services main CoreSession object is reused alot (e.g. in the authentication interceptor we use the same session object no matter who the caller is).

      I was interested in putting in a short-term patch to work-around this issue while a longer term solution was considered. But I couldn't find anything obvious. I'd think it would make sense to stuff the client address into the session somewhere up in one of the protocol handlers (e.g. LdapRequestHandler.handleMessage) ... but there currently isn't anywhere to put this info. Any ideas on a short-term (even if hacky) way to achieve this?

      (raising as requested by Emmanuel Lecharany on user's list)

      1. connection-info-1.5.5-v2.patch
        6 kB
        Matt Doran
      2. connection-info-1.5.5.patch
        2 kB
        Matt Doran

        Activity

        Hide
        Kiran Ayyagari added a comment -

        Added another fix to provide the connection information when an operation was performed anonymously, see http://svn.apache.org/r1505919

        Show
        Kiran Ayyagari added a comment - Added another fix to provide the connection information when an operation was performed anonymously, see http://svn.apache.org/r1505919
        Hide
        Emmanuel Lecharny added a comment -
        Show
        Emmanuel Lecharny added a comment - Fixed with http://svn.apache.org/r1485239
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Version 2.0.0-M3 has been released a couple months ago.

        Assigned the remaining opened JIRA to the next iteration (2.0.0-M4).

        Show
        Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M3 has been released a couple months ago. Assigned the remaining opened JIRA to the next iteration (2.0.0-M4).
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Version 2.0.0-M1 has been released.
        Moving all related non-resolved issues to the next version.

        Show
        Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M1 has been released. Moving all related non-resolved issues to the next version.
        Hide
        Emmanuel Lecharny added a comment -

        Sounds a good idea. Let's check the path and apply it before 2.0

        Show
        Emmanuel Lecharny added a comment - Sounds a good idea. Let's check the path and apply it before 2.0
        Hide
        Matt Doran added a comment -

        I've updated the patch to also passed down the client address into the bind requests. This required some changes up in the protocol handler, and some hacky stuff in the BindHandler to copy this down throught the layers.

        The flow of data through the layers of interceptors, etc is pretty darn complex..... and I'd have to say difficult to understand and probably brittle. But what do I know?

        Show
        Matt Doran added a comment - I've updated the patch to also passed down the client address into the bind requests. This required some changes up in the protocol handler, and some hacky stuff in the BindHandler to copy this down throught the layers. The flow of data through the layers of interceptors, etc is pretty darn complex..... and I'd have to say difficult to understand and probably brittle. But what do I know?
        Hide
        Matt Doran added a comment -

        Updated version of patch that will also push the client address down into the bind requests.

        Show
        Matt Doran added a comment - Updated version of patch that will also push the client address down into the bind requests.
        Hide
        Matt Doran added a comment -

        Initial rough patch to push connection details into the session so it's accessible elsewhere.

        Show
        Matt Doran added a comment - Initial rough patch to push connection details into the session so it's accessible elsewhere.
        Hide
        Matt Doran added a comment -

        I've dug into this a bit and have a patch that goes part of the way (see attached).

        It does the following:

        • Adds storage for the client address on the DefaultCoreSession, and adds a setter.
        • Sets the network address in LdapRequestHandler.handleMessage().

        I've only set the connection in one location in handleMessage() which seemed to be what was needed for my "authenticated" sessions. But I didn't do this in the unauthenticated case yet (but that might be ok too). There's also some other cases, like for the "InternalBindRequest", which I don't understand so didn't touch.

        It also seems like some "lookup" requests down into the partition don't use the same session (maybe internal sessions used in the bind/authenticate process) ... but maybe that's ok too if they are doing internal things.

        I've created the patch against 1.5.5 because the custom partition examples haven't been updated yet (neither have the external maven repos with the 1.5.6 jars and sources).

        Show
        Matt Doran added a comment - I've dug into this a bit and have a patch that goes part of the way (see attached). It does the following: Adds storage for the client address on the DefaultCoreSession, and adds a setter. Sets the network address in LdapRequestHandler.handleMessage(). I've only set the connection in one location in handleMessage() which seemed to be what was needed for my "authenticated" sessions. But I didn't do this in the unauthenticated case yet (but that might be ok too). There's also some other cases, like for the "InternalBindRequest", which I don't understand so didn't touch. It also seems like some "lookup" requests down into the partition don't use the same session (maybe internal sessions used in the bind/authenticate process) ... but maybe that's ok too if they are doing internal things. I've created the patch against 1.5.5 because the custom partition examples haven't been updated yet (neither have the external maven repos with the 1.5.6 jars and sources).

          People

          • Assignee:
            Unassigned
            Reporter:
            Matt Doran
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development