[jcifs] Re: SMB URL encoding/decoding

Christopher R. Hertel crh at ubiqx.org
Sun Feb 24 15:09:59 EST 2002


Michael B Allen wrote:
> 
> On Sun, 24 Feb 2002 02:52:09 +0100
> James Nord <teilo at teilo.net> wrote:
> 
> > by the way,
> >
> > |the example on |http://jcifs.samba.org/src/docs/api/jcifs/smb/SmbFile.html
> > |
> >      smb://Administrator:P@ss@msmith1/c/WINDOWS/Desktop/foo.txt|
> >             - A relativly sophisticated example that references a file
> > |msmith1|'s desktop as user |Administrator|.
> >
> > Is this not illegal according to the draft?
> 
> I don't think you HAVE to encode everything. Its a good idea and a
> necessity to ensure there is no ambiguity. In practice jCIFS does not
> decode anything after the authentication creadentials because requiring
> a user to URL encode their password is just going a little too far I
> think. 

I understand the reasoning here.  It's a pain to encode password
characters.  It would be nice if you could quote the entire password string
somehow.  Unfortunately, the <userinfo> field is allowed the following:

      userinfo      = *( unreserved | escaped |
                         ";" | ":" | "&" | "=" | "+" | "$" | "," )

      unreserved    = alphanum | mark
      mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
                      "(" | ")"

      escaped       = "%" hex hex
      hex           = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                              "a" | "b" | "c" | "d" | "e" | "f"

Note that the '/' is not in that list.  It's not a legal character within
the <userinfo> field, so it must be encoded using the <escaped> syntax.

> And if you decode it at all, you know have to require encoding
> '+' and '%' and yada yada yada.

That's how URLs are handled, I'm afraid.

> So we search in from the end for '@'
> and don't encode/decode anything before the server.

That's how jCIFS does it, but it isn't how others will handle it.

URL parsing is supposed to be as generic as possible until you get to the
individual fields recognized by general URL syntax.  Those fields may then
have scheme-specific syntax.

It is an object-oriented kind of thing.  The specific schemes are descendent
from the general URI format.

So, we should be able to pass an SMB URL string to a generic URL parser and
get back the generic URL fields.  We might then need to further parse the
<userinfo> into <user> and <password> based on the ':' character (since the
RFCs suggest against this, some of the generic parsers out there don't
actually parse that field...others do).  Once we have <user> we would look
for ';' to see if we need to parse out the <ntdomain>.

James Nord wrote:
> 
> by the way,
> 
> |the example on |http://jcifs.samba.org/src/docs/api/jcifs/smb/SmbFile.html
> |
>      smb://Administrator:P@ss@msmith1/c/WINDOWS/Desktop/foo.txt|
>             - A relativly sophisticated example that references a file
> |msmith1|'s desktop as user |Administrator|.
> 
> Is this not illegal according to the draft?

The two '@'s are a problem, I suppose.  The way that this would be parsed
is:

scheme == "SMB"
server == "Administrator:P at ss@msmith1"
path   == "src/docs/api/jcifs/smb/SmbFile.html"

The <server> field would then be further parsed into <userinfo>@<hostport>,
probably based on the first '@'.  That would give:

userinfo == "Administrator:P"
hostport == "ss at msmith1"

Probably not what was intended.

One of those '@'s should probably be escaped.  I'll assume it's the first.
That gives:  "Administrator:P%40ss at msmith1" which results in:

userinfo == "Administrator:P%40ss"
hostport == "msmith1"

The <userinfo> is then further parsed to:
user   == "Administrator"
passwd == "P%40ss"

...and <passwd> is un-escaped to the correct password.

The result is user Administrator with password P at ss logging onto server
msmith1.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org




More information about the jcifs mailing list