[jcifs] filtering the users home share (Was Re: davenport filters)

Mike Manley Mike at technomyth.co.uk
Fri Dec 17 23:58:52 GMT 2004


Michael B Allen wrote:

>On Fri, 17 Dec 2004 11:37:42 +0000 (UTC)
>Mike Manley <Mike at technomyth.co.uk> wrote:
>
>  
>
>>At the moment, modifying jcifs.smb.smbFile to give access to the
>>information I want would seem the simplest way of doing this. My only
>>other option would be to dig deeper into the internal of davenport to see
>>if I can somehow pass the username through to the file filter as part of
>>the init.
>>    
>>
>
>What attributes are in the HttpSession? You could modify davenport to
>add a "username" attribute or something like that.
>  
>
I've spent some more time today looking through the davenport code and 
set the Log Level to DEBUG.
I've now found where davenport creates and initializes the filters. 
Unfortunately, this is at the point when
a client first connects to davenport and before it asks for 
authentication so the username isn't available
at that time. I spent Also, the filters are only created and initialized 
once, the first time any client connects.
If I connect a second client the same filter objects must be re-used so 
I don't think putting the username
into an attribute of the filter is an option, as I can't see how it 
would be possible to ensure that the
currently set username on the filter matched the session currently being 
filtered when several clients were
connecting at the same time.

>I an not entirely against the idea of adding:
>
>public Principal getPrincipal() {
>	return auth;
>}
>
>Then you can do:
>
>String username = f.getPrincipal().getName();
>  
>
I think this is probably my only viable option at this point. I think 
I'll try it and see if I can achieve the
result I want.

>I only hesitate because the plan is to stop development of 1.x and work
>on 2.x. But this is a pretty simple change. I'll think about it.
>
>In 2.x when we try to integrate subject based security more things will be
>very different. I believe the security context should probably be associated
>with the current thread (the only problem with that is that without language
>support the security context cannot easily be inherited).
>  
>
Many thanks for your help

Mike


More information about the jcifs mailing list