After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 628430 - Password are not recognized in URIs
Password are not recognized in URIs
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: general
1.12.x
Other Linux
: Low enhancement
: ---
Assigned To: gvfs-maint
gvfs-maint
: 520915 538432 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-08-31 15:44 UTC by Kamil Páral
Modified: 2017-02-13 11:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example screenshot (355.89 KB, image/png)
2010-08-31 15:44 UTC, Kamil Páral
  Details
client: Ignore everything after first colon in userinfo (2.03 KB, patch)
2017-01-20 13:43 UTC, Ondrej Holy
committed Details | Review

Description Kamil Páral 2010-08-31 15:44:25 UTC
Created attachment 169172 [details]
example screenshot

Nautilus in its address bar accepts URLs like:
ftp://server.com
ftp://user@server.com

But it does not accept URL like:
ftp://user:password@server.com
that is really common and web browsers understand it.

Instead, Nautilus thinks that whole "user:password" is a login name and asks for password.

This is wrong, it should split this string using colon and parse the password correctly out of it.
Comment 1 Kamil Páral 2010-08-31 15:44:55 UTC
nautilus-2.31.90-1.fc14.x86_64
Fedora 14
Comment 2 Matt Joiner 2011-01-20 09:43:21 UTC
I can confirm this bug, it's easily reproduced.

Execute 'nautilus ftp://user:pass@somehost' on the command line. The username is treated as 'user:pass', and then the password is requested in the dialog.
Comment 3 Matt Joiner 2011-01-20 09:49:55 UTC
I can't work out this bug tracker system, but this bug affects more than just the location bar, I believe it affects any URL handling that nautilus does.
Comment 4 Stefano Teso 2011-03-06 14:05:14 UTC
Thanks for your bug report. Nautilus That's because nautilus uses g_vfs_decode_uri function (part of gvfs) to perform URI decoding. That particular function follows RFC 3986. The latter states, in section 3.2.1 ("User Information"):

----

   Use of the format "user:password" in the userinfo field is
   deprecated.  Applications should not render as clear text any data
   after the first colon (":") character found within a userinfo
   subcomponent unless the data after the colon is the empty string
   (indicating no password).  Applications may choose to ignore or
   reject such data when it is received as part of a reference and
   should reject the storage of such data in unencrypted form.  The
   passing of authentication information in clear text has proven to be
   a security risk in almost every case where it has been used.

   Applications that render a URI for the sake of user feedback, such as
   in graphical hypertext browsing, should render userinfo in a way that
   is distinguished from the rest of a URI, when feasible.  Such
   rendering will assist the user in cases where the userinfo has been
   misleadingly crafted to look like a trusted domain name
   (Section 7.6).

----

And section 7.5:

----

7.5.  Sensitive Information

   URI producers should not provide a URI that contains a username or
   password that is intended to be secret.  URIs are frequently
   displayed by browsers, stored in clear text bookmarks, and logged by
   user agent history and intermediary applications (proxies).  A
   password appearing within the userinfo component is deprecated and
   should be considered an error (or simply ignored) except in those
   rare cases where the 'password' parameter is intended to be public.

----

Now, nautilus (or rather gvfs) should probably be a bit smarter and detect whether the login contains a colon, and strip everything from the colon to the @ sign, so that the password is (a) not transmitted plaintext over the net, (b) warn the user that this particular format is deprecate.

Or just ignore the RFC and implement this feature to conform to existing web browsers...
Comment 5 Matt Joiner 2011-03-07 02:20:28 UTC
Can you advise a workaround for this? I'd like to invoke FTP URLs with password via the shell.
Comment 6 Kamil Páral 2011-03-07 11:18:06 UTC
I understand the RFC in means of rendering. The password should not be shown. But I would advise to accept it as an input. That is exactly the case in Firefox. It accepts the format as an input, but then renders it the address bar without the password.
Comment 7 Felix Möller 2011-03-23 21:28:14 UTC
I just wanted to report this issue. It is quiet annoying as people are used to be able to use these urls.

I am not sure how to read the RFC yet.
Comment 8 Jani Uusitalo 2012-03-27 16:16:53 UTC
This looks like a duplicate of bug 538432 [1] though it refers to a different memo, RFC1738.

* [1] https://bugzilla.gnome.org/show_bug.cgi?id=538432
Comment 9 Felix Möller 2012-03-28 15:39:15 UTC
I think the component of this bug is off.

I can reproduce it with plain gvfs-mount on the commandline:
gvfs-mount ftp://user:pass@server/
Comment 10 Cosimo Cecchi 2012-03-28 15:58:48 UTC
*** Bug 538432 has been marked as a duplicate of this bug. ***
Comment 11 Cosimo Cecchi 2012-03-28 16:05:21 UTC
-> gvfs
Comment 12 Tomas Bzatek 2012-03-28 16:19:30 UTC
While we can detect, decode and use password from the URI given (not saving it in keyring), the way GIO has been designed you'd still see the original URI everywhere. It's a key string that makes it possible to match existing mounts. So that ftp://user:pass@server/ and ftp://user@server/ would be two different mounts. And that would create another level of confusion, just like ftp://user@server/ and ftp://server/ do.
Comment 13 Felix Möller 2012-08-02 08:27:21 UTC
I think bug #520915 should be marked as a duplicate of this one.
Comment 14 Cosimo Cecchi 2012-08-02 08:28:54 UTC
*** Bug 520915 has been marked as a duplicate of this bug. ***
Comment 15 Andrej Czapszys 2017-01-17 00:15:18 UTC
I would like to see this feature implemented.  It is handy to be able to open locations from the command line with the password included.
Comment 16 Ondrej Holy 2017-01-17 12:08:00 UTC
I am afraid of that we don't want support passwords in URIs, because it is a security issue. However, we should remove them from the usernames at least if it is not fixed already...
Comment 17 Ondrej Holy 2017-01-20 12:16:15 UTC
From https://tools.ietf.org/html/rfc3986#section-3.2.1:

Use of the format "user:password" in the userinfo field is
deprecated.  Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password).  Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form.  The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
Comment 18 Ondrej Holy 2017-01-20 13:43:30 UTC
Created attachment 343900 [details] [review]
client: Ignore everything after first colon in userinfo

Use of the format "user:password" in the userinfo field is deprecated
and applications should not render as clear text any data after the
first colon as per rfc3986. Passwords have never been handled in
userinfo fields by GVfs, however, they are still part of the usernames,
which is wrong. Let's ignore such data in userinfo fileds.
Comment 19 Ondrej Holy 2017-02-13 11:49:51 UTC
Attachment 343900 [details] pushed as 2417271 - client: Ignore everything after first colon in userinfo