[vfs] providing smb credentials somewhere other than the URI

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[vfs] providing smb credentials somewhere other than the URI

Dion Gillard-2
Is it possible to pass username/password to the FileSystemManager or
some other object so that the URI doesn't need the username/password
combo?

e.g. I'd rather not do a

FileSystemManager.resolveFile("smb://user:password@host/share/file")

and instead do

FileSystemManager.resolveFile("smb://host/share/file", ???OPTIONS???)

Any ideas?
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] providing smb credentials somewhere other than the URI

Mario Ivankovits
Hi!
>Is it possible to pass username/password to the FileSystemManager or
>some other object so that the URI doesn't need the username/password
>combo?
>  
Currently: No.

But I updated the todo list and added this as a feature of release 1.1.

After this we should have a uniform way how to pass credentials to the
underlaying filesystem without the need to add them to the url.


---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] providing smb credentials somewhere other than the URI

Philippe Poulard
Mario Ivankovits wrote:

> Hi!
>
>> Is it possible to pass username/password to the FileSystemManager or
>> some other object so that the URI doesn't need the username/password
>> combo?
>>  
>
> Currently: No.
>
> But I updated the todo list and added this as a feature of release 1.1.
>
> After this we should have a uniform way how to pass credentials to the
> underlaying filesystem without the need to add them to the url.
>

what about using attributes as we talk in another post ?

moreover, user/pwd are attributes which name should be normalized
Map map = new HashMap();
// 2 attributes that are consumed by VFS
map.put( "org.apache.commons.vfs.User", user );
map.put( "org.apache.commons.vfs.Password", password );
// 1 attribute consumed by the XML:DB scheme
map.put( "org.apache.commons.vfs.provider.xmldb.ResourceType",
"XMLResource" );
// 1 attribute consumed by the XML:DB provider
map.put( "org.foo.xmldbdriver.Cluster", "myCluster" );

then create the file as you suggested previously :
FileObject.createFile( map );

an attribute consumed at a level is not passed to the next stage ; no
confusion with the attribute names because one uses fully qualified
names, so a target just have to announce that it consumes some attributes
just a problem to solve : how to deal with a scheme that may contain
itself as a scheme, if attributes are used, which one is the target ?
foo:foo:///path/to/file!/path/to/file
do we have to prefix the attribute name :
"org.foo.Bar" -> the external scheme is the target
"foo:org.foo.Bar" -> the internal scheme is the target
mmmh, unwrapping attribute names could be done automatically by VFS if
this idea was retained

advice ?

--
Cordialement,

            ///
           (. .)
  -----ooO--(_)--Ooo-----
|   Philippe Poulard    |
  -----------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] providing smb credentials somewhere other than the URI

Mario Ivankovits
Philippe Poulard wrote:

> what about using attributes as we talk in another post ?
>
> moreover, user/pwd are attributes which name should be normalized
> Map map = new HashMap();
> // 2 attributes that are consumed by VFS
> map.put( "org.apache.commons.vfs.User", user );
> map.put( "org.apache.commons.vfs.Password", password );
> // 1 attribute consumed by the XML:DB scheme
> map.put( "org.apache.commons.vfs.provider.xmldb.ResourceType",
> "XMLResource" );
> // 1 attribute consumed by the XML:DB provider
> map.put( "org.foo.xmldbdriver.Cluster", "myCluster" );
>
> then create the file as you suggested previously :
> FileObject.createFile( map );
username/password aren't file level attributes. A server might present
you a different set of files depending on the user you used for "login".
We already have a logic to pass down such filesystem attributes using
the *ConfigBuilder classes.
They provide type-safety and in-code documentation of all possible
options depending on the scheme e.g. HttpFileSystemConfigBuilder

BTW I dont like the idea of having just key/value pairs of strings where
no one knows which keys are possible and what the value means.

The configBuilder accepts an instance of FileSystemOptions where these
options are stored then.

FileSystemOptions opts = new FileSystemOptions();
HttpFileSystemConfigBuilder.getInstance().setProxyHost(opts, "proxy");
FtpFileSystemConfigBuilder.getInstance().setPassiveMode(opts, true);

FileObject fo = VFS.getInstance().resolveFile("any/file", opts);

Depending on which FileProvider is needet during resolveFile the
Filesystem will pick its configuration ...
> just a problem to solve : how to deal with a scheme that may contain
> itself as a scheme, if attributes are used, which one is the target ?
> foo:foo:///path/to/file!/path/to/file
... see above.

To just processs strings of key/value entries, say to configure a
filesystem in an ant task one can use the
DelegatingFileSystemOptionsBuilder e.g.
delegate.setConfigString(fso, "http", "proxyPort", "8080");

Reflection will be used to check if the parameters are valid. So we have
a fail-fast on configuration errors.


Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] providing smb credentials somewhere other than the URI

Philippe Poulard
Mario Ivankovits wrote:

> Philippe Poulard wrote:
>
>> what about using attributes as we talk in another post ?
>>
>> moreover, user/pwd are attributes which name should be normalized
>> Map map = new HashMap();
>> // 2 attributes that are consumed by VFS
>> map.put( "org.apache.commons.vfs.User", user );
>> map.put( "org.apache.commons.vfs.Password", password );
>> // 1 attribute consumed by the XML:DB scheme
>> map.put( "org.apache.commons.vfs.provider.xmldb.ResourceType",
>> "XMLResource" );
>> // 1 attribute consumed by the XML:DB provider
>> map.put( "org.foo.xmldbdriver.Cluster", "myCluster" );
>>
>> then create the file as you suggested previously :
>> FileObject.createFile( map );
>
> username/password aren't file level attributes. A server might present
> you a different set of files depending on the user you used for "login".
> We already have a logic to pass down such filesystem attributes using
> the *ConfigBuilder classes.
> They provide type-safety and in-code documentation of all possible
> options depending on the scheme e.g. HttpFileSystemConfigBuilder
>
> BTW I dont like the idea of having just key/value pairs of strings where
> no one knows which keys are possible and what the value means.
>
> The configBuilder accepts an instance of FileSystemOptions where these
> options are stored then.
>
> FileSystemOptions opts = new FileSystemOptions();
> HttpFileSystemConfigBuilder.getInstance().setProxyHost(opts, "proxy");
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(opts, true);
>
> FileObject fo = VFS.getInstance().resolveFile("any/file", opts);
>
> Depending on which FileProvider is needet during resolveFile the
> Filesystem will pick its configuration ...
>
>> just a problem to solve : how to deal with a scheme that may contain
>> itself as a scheme, if attributes are used, which one is the target ?
>> foo:foo:///path/to/file!/path/to/file
>
> ... see above.
>
> To just processs strings of key/value entries, say to configure a
> filesystem in an ant task one can use the
> DelegatingFileSystemOptionsBuilder e.g.
> delegate.setConfigString(fso, "http", "proxyPort", "8080");
>
> Reflection will be used to check if the parameters are valid. So we have
> a fail-fast on configuration errors.
>

ok, i begin to understand that what I called "attributes" seems to be
"file system options" in some cases...

thanks for your reply

--
Cordialement,

            ///
           (. .)
  -----ooO--(_)--Ooo-----
|   Philippe Poulard    |
  -----------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]