Directory listing in libsmbclient.so

[Simo Sorce]

On Thu, 28 Dec 2000, Steve Langasek wrote:

> On Wed, 27 Dec 2000, Christopher R. Hertel wrote:
>
> > > > Also, jcifs uses the following syntax to specify a resource as a URL:
> > > > smb://domain\user:password@host:port/share/dir/file
>
> > If possible, it would be nice to get rid of the backslash. ('\')  I would
> > like to see a nominal standard come out of this discussion.
>
> In this case, the Microsoft obsession with the backslash has proved rather
> fortuitous.  Putting aside the necessity of escaping the character at the
> commandline, the domain\user syntax is quite easy to incorporate into URIs of
> other types.  For instance, we have an NT ftp server which authenticates
> against a Samba-controlled domain.  When logging in, users have to specify the
> domain name as part of the username to log in.  Domain\user can be specified
> as part of an ftp url without any problems, whereas using another separator
> character could have caused problems (e.g. @, :, %, or /).
>
> > > Effectively, 'domain\user' is the username you're using for authentication.
> > > What if a user wishes to browse workgroup2, using his credentials from
> > > domain1?  This should be allowed, and with inter-domain trust relationships it
> > > may even be necessary.
>
> > An ntdomain is simply an extension of a workgroup.  The ntdomain provides
> > the additional functionality of:
> > - Cross-subnet browsing (via the DMB, but this is not significant to this
> >   discussion)
> > - A single sign-on.
>
> > This latter is the critical point, but it can be hidden from the user.
> > The syntax of the URI does not need to be different and the user should
> > *not* need to care if the name represents a workgroup or an ntdomain.
>
> Yes, the specification of the username can be hidden from the user.  But if
> we're not going to support a full URL syntax, including allowing the
> specification of the username within the URL, why bother trying to make it
> look like a URL?  I think it's perfectly reasonable to think that someone may
> occasionally want to browse the network using credentials other than the
> default, and that a domain name will need to be specified as part of these
> credentials.
>
> Is there functionality we lose if a workgroup and a domain can't be specified
> at the same time?  Not to my knowledge, because authentication info isn't used
> when retrieving browse lists.  Still, a user that has manually specified
> credentials will probably want those credentials to be preserved while
> browsing, which means encoding them in the URL that calls up the browse list.
> The client lib /could/ hide the credentials and simply cache them internally,
> but again, if we're going to start hiding information from the user or forcing
> her to use a GUI to make changes, why bother with URLs at all?
>
> Of course now that I've made this argument, I also see that if we're going
> to cache authentication information in the URL that has no bearing on
> browsing, it's just as useful to cache browse list information in a URL that's
> used for direct access to a resource for which the workgroup membership of the
> server is irrelevant.

agree, and say that many sysadmin and users really need a way to specify a
username/password.
About caching I will cache only the password removing it from the URL but
I will not remove the username.

>
> > Right, they are not heirarchical, but then neither are NetBIOS names.
> > Still, if there are multiple workgroups/ntdomains available on the local
> > wire, then the user should be able to access then all.  To do so, you
> > need to be able to specify the workgroup.  I see no reason to lock this
> > down in a config file.
>
> I agree completely.  I just don't want the workgroup to be specified in such a
> way that it causes confusion between workgroups and servers, which I think
> will happen if the workgroup ends up where other URL schemes place the
> hostname.
>
> > A browse list can be thought of as a directory.  It's not much
> > different.  The hierarchy would be:
>
> > workgroup/ntdomain
> >      \----> Server
> >               \----> service
> >                         \----> directory
>
> >
> smb://workgroup/[user[:password]@]host[.domain][:port]/[directory/[subdir/]][file]
> >   smb://
>
> >   smb://workgroup/
>
> I think it's to our advantage if a URL such as smb://<server>/<share>/ works
> just as it does for ftp or http urls.  I think the above scheme is close to
> what is needed, but I'd like to avoid seeing smb:///<server>/<share>/, which
> is what's required here to disambiguate between a workgroup name and a server
> name.  One possibility that would be consistent with RFC 1738 is
>
>   smb:/[workgroup]/[user[:password]@]host[.domain][:port]/[share][/...]
>
> Then
>
>   smb://
>
> gives a browse list of hosts in your default workgroup,
>
>   smb:/
>
> gives a list of available workgroups on the network, and
>
>   smb:/workgroup/
>
> lists hosts in the specified workgroup.  I have mixed feelings about putting
> anything between those first two slashes, which have come to be nearly
> universal, but this scheme does have two advantages that I see.  First,
> smb://server/ works as expected, so the principle of least surprises holds;
> and second, the workgroup name can be encoded in a manner suggesting heirarchy
> but not attempting to enforce it.  This scheme is one that people already
> familiar with URLs and SMB filesharing could start using with no learning
> curve, and a good interface could familiarize them with the new workgroup
> syntax without much trouble.
>

I think the following is better:

smb://[[domain/]user[:password]@][workgroup#]server[/share/../..]

smb://
will give a list of workgroups
smb://workgroup
will give a list of servers in the workgroup
smb://server
will give a list of shares in the server

the last 2 should work without trouble as workgroups and servers can't
have the same name!

-- 
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
-----------------------------------------------------------------
Be happy, use Linux!