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:pwd@www.proxy.com: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??
···
--
anatol (http://pomozov.info)
In article <3665a1a00512111049n6fe237a1i7cefbceb25bf07cf@mail.gmail.com>,
Anatol Pomozov <anatol.pomozov@gmail.com> writes:
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:pwd@www.proxy.com: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).
--
Tanaka Akira