[ 
https://issues.apache.org/jira/browse/DIRSERVER-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716176#comment-13716176
 ] 

Kiran Ayyagari commented on DIRSERVER-1489:
-------------------------------------------

Added another fix to provide the connection information when an operation was 
performed anonymously, see http://svn.apache.org/r1505919
                
> 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
>             Fix For: 2.0.0-M13
>
>         Attachments: connection-info-1.5.5.patch, 
> connection-info-1.5.5-v2.patch
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to