Directory listing in libsmbclient.so

[Steve Langasek]

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.

> 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.

Steve Langasek
postmodern programmer