[
https://issues.apache.org/jira/browse/DIRSERVER-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850775#action_12850775
]
Matt Doran commented on DIRSERVER-1489:
---------------------------------------
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).
> Provide access to remote connection info
> ----------------------------------------
>
> Key: DIRSERVER-1489
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1489
> Project: Directory ApacheDS
> Issue Type: Improvement
> Affects Versions: 1.5.5
> Reporter: Matt Doran
>
> 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)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
