SMBC_parse_path doesn't seem to handle special characters

[Eduardo Kienetz]

On Sun, Jan 24, 2010 at 5:16 AM, Volker Lendecke
<Volker.Lendecke at sernet.de>wrote:

> On Sun, Jan 24, 2010 at 12:32:25AM -0600, Eduardo Kienetz wrote:
> > Agreed, but the bottom line is that that's supported, because some
> developer
> > had [good?] reasons to do so, and it doesn't work right :)
>
> True. But then to cover that 100% we need a proper escaping
> mechanism, something like quoted-printable or base64-encoded
> utf8 (like LDAP does) that fits into the url scheme.
>

Oh, you mean we should require the password to be base64 encoded? Doesn't
seem that good since it still might return / in it (unless we use modified
versions).

I think what would solve our problem once and for all is to require escaping
the @s that are part of the password. That would also eliminate the need for
my first patch.
e.g.: smb://user:p\@ss/word\\@m@serv@r/m@share/m@filename.txt
In this case we'd have:
1) password (the backslah right before the @ was for escaping): p at ss/word\@m
2) server: serv at r
3) share: m at share
...

This way we'd look for the first : (indicating a password separator,
usernames can't contain :), then just look for the next unescaped @ (server
separator).

The reason I'm a bit reluctant to put in your patch directly
> is the fact that I personally are always scared by
> string-parsing. This code is already very hard to
> understand for me.
>

Well, it's quite simple though, but it'll not be needed once I use the
escaping idea from above :)
Hold on tight.


> > P.S.: it looks like I'll have to create a
> > "get_last_token_no_ltrim_talloc()", so that I can use at libsmb_path.c
> > instead of next_token_no_ltrim_talloc(ctx, &p, &userinfo, "@"). That's to
> > support parsing URLs with passwords containing @ (clarifying what I said
> in
> > my first e-mail).
>
> Hehe, that kindof supports my statement "string parsing is
> scary", doesn't it? :-)
>

Indeed, but I realized it wouldn't really help since server name, share name
and file/folder can contain @.
I'm glad I realized backslashing the @s in the password would be enough to
solve everything, if I didn't miss anything, as it seems to me :)

Hold on, will submit it asap.

Eduardo Bacchi Kienetz