Forum: Ruby About open-uri and ENV

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Anatol P. (Guest)
on 2005-12-11 20:50
(Received via mailing list)
Hi, all.

I am investigating problem with Gems and proxy authorization and I have
question about open-uri code.
To be precise code from OpenURI.open_loop(uri, options) (Current version
from CVS)

    when :proxy
      opt_proxy = options.fetch(:proxy)
      proxy_user = nil
      proxy_pass = nil

proxy option mostly come from ENV and could contain information for
basic
authorization: username and password. Something like this
http://anatol:removed_email_address@domain.invalid:8080/
and right way is parse this string and put proxy_user to anatol,
proxy_pass
to pwd and proxy_url to http://www.proxy.com:8080/

The same with code a bit below
    when true
      find_proxy = lambda {|u| pxy = u.find_proxy; pxy ? [pxy, nil, nil]
:
nil}

It should be
    when true
      find_proxy = lambda {|u| pxy = u.find_proxy; pxy ?
parse_proxy_and_find_authorization_info(pxy) : nil}


Is it logical??
Tanaka A. (Guest)
on 2005-12-12 04:33
(Received via mailing list)
In article
<removed_email_address@domain.invalid>,
  Anatol P. <removed_email_address@domain.invalid> writes:

> proxy option mostly come from ENV and could contain information for basic
> authorization: username and password. Something like this
> http://anatol:removed_email_address@domain.invalid:8080/
> and right way is parse this string and put proxy_user to anatol, proxy_pass
> to pwd and proxy_url to http://www.proxy.com:8080/

Environment variables are not appropriate place to store
passwords since they are visible from other users.

Note that RFC 3986 deprecates "user:password" in the
userinfo field.

| 3.2.1.  User Information
|
|    The userinfo subcomponent may consist of a user name and, optionally,
|    scheme-specific information about how to gain authorization to access
|    the resource.  The user information, if present, is followed by a
|    commercial at-sign ("@") that delimits it from the host.
|
|       userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )
|
|    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).
This topic is locked and can not be replied to.