I have downloaded and installed R (3.4.1)and R studio (1.0.153) on MAC OS ( El Captain). I am facing trouble setting up the proxy. I am trying to install some packages from CRAN.
I referred to https://support.rstudio.com/hc/en-us/articles/200488488-Configuring-R-to-Use-an-HTTP-or-HTTPS-Proxy
I was able to set up proxy and used properties
http_proxy=http://MYSERVER:MYPORT
http_proxy_user=user:passwd
I enabled options(internet.info = 0) option to get a trace of internet access from R Studio.
While the proxy server set up looks good in logs, its not able to get authentication.
Here are the logs:
Connected to MYSERVER port MYPORT (#0)
> GET http://cran.rstudio.com/src/contrib/PACKAGES.gz HTTP/1.1
Host: cran.rstudio.com
User-Agent: R (3.4.1 x86_64-apple-darwin15.6.0 x86_64 darwin15.6.0)
Accept: */*
Proxy-Connection: Keep-Alive
Pragma: no-cache
* The requested URL returned error: 407 Proxy Authentication Required
* Closing connection 0
Warning: unable to access index for repository http://cran.rstudio.com/src/contrib:
cannot open URL 'http://cran.rstudio.com/src/contrib/PACKAGES'
(Please note: I have replaced the proxy server and port )
I tried changing the
http_proxy_user=ask
As suggested in one of the work around I read, but that also didn't work.
Could anyone suggest how to set up proxy authentication properly in R studio on Mac?
I have Eclipse installed on my local using the same proxy port and authentication and it is able to download stuff fine.
I am able to hit the url http://cran.rstudio.com/src/contrib/PACKAGES.gz directly in firefox.
I was finally able to make it work. The user id and password was accepted by adding them in the same property
http_proxy=http://username:password#proxyServer:port
This created another issue, my password contained # char, which is why the proxy url was messed up. I referred to another post on stacktrace which suggested to try urlencoding the "#" in the password to %40, With this change, it finally went through the proxy.
options(internet.info = 0) helped look through the detailed log which helped solve the issue.
Related
I'm interested to check if my package is compatible with the windows platform. The library was developed on debian system Platform: x86_64-pc-linux-gnu (64-bit). In order to check windows' comparability I run devtools::check_win_release() which leads me to errors with connection time out:
It first asks for email confirmation to which I confirm.
Error in curl::curl_fetch_memory(url, handle = h) :
Timeout was reached: [win-builder.r-project.org] Connection timed out after 10001 milliseconds
I spoke to the IT admin and they have set a firewall for security measures and forbid interaction via curl or any other utilities. I've proxy settings set as suggested by the IT-admin but again they are in vain.
Is there any way I can check windows build?
I've tried options(timeout = 4000000) but the error persists.
R 4.0 devtools_2.3.1 testthat_2.3.2
There is no build_win
I'm using http://r-pkgs.had.co.nz/release.html as my resource.
Edit: Sys.getenv("http_proxy") and Sys.getenv("https_proxy") print the proxy settings set in the bash environment variable.
My institute recently installed a new proxy server for our network. I am trying to configure my Cygwin environment to be able to run wget and download data from a remote repository.
Browsing the internet I have found two different solutions to my problem, but no one of them seem to work in my case.
The first one I tried was to follow these instructions, so in Cygwin:
cd /cygdrive/c/cygwin64/etc/
nano wgetrc
at the end of the file, I added:
use_proxy = on
http_proxy=http://username:password#my.proxy.ip:my.port/
https_proxy=https://username:password#my.proxy.ip:my.port/
ftp_proxy=http://username:password#my.proxy.ip:my.port/
(of course, using my user and password)
The second approach was what was suggested by this SO post, so in my Cygwin environment:
export http_proxy=http://username:password#my.proxy.ip:my.port/
export https_proxy=https://username:password#my.proxy.ip:my.port/
export ftp_proxy=http://username:password#my.proxy.ip:my.port/
in both cases, if I try to test my wget, I get the following:
$ wget http://www.google.com
--2020-01-30 12:12:22-- http://www.google.com/
Resolving my.proxy.ip (my.proxy.ip)... 10.1XX.XXX.XX
Connecting to my.proxy.ip (my.proxy.ip)|10.1XX.XXX.XX|:8XXX... connected.
Proxy request sent, awaiting response... 407 Proxy Authentication Required
2020-01-30 12:12:22 ERROR 407: Proxy Authentication Required.
It looks like if my user and password are not ok, but I actually checked them on my browsers and my credentials work just fine.
Any idea on what this could be due to?
This problem was solved thanks to the suggestion of a User of the community AskUbuntu.
Basically, instead of editing the global configuration file wgetrc, I should have created a new .wgetrc with my proxy configuration in my Cygwin home directory.
In summary:
Step 1 - Create a .wgetrc file;
nano ~/.wgetrc
Step 2 - record in this file the proxy info:
use_proxy=on
http_proxy=http://my.proxy.ip:my.port
https_proxy=https://my.proxy.ip:my.port
ftp_proxy=http://my.proxy.ip:my.port
proxy_user=username
proxy_password=password
I have just installed an intermediate & primary SSL certificate on my VPS. Everything is working well, except when I make a cfhttp call:
<cfhttp url="https://advert.establishmindfulness.com/ad-zone-1/?categoryid=1" method="get" result="adzone" />
<cfdump var="#adzone#" />
From https://app.establishmindfulness.com to https://advert.establishmindfulness.com. These 2 subdomains are on the same server, and I am using a wildcard SSL certificate:
*.establishmindfulness.com
That covers all sub domains.
VPS environment
OS: Windows 2008R2 with IIS7
Application server: Lucee 4.5.2.018 final
Servlet Container: Apache Tomcat/8.0.28
Java: 1.8.0_66 (Oracle Corporation) 64bit
Do I need to install the intermediate.crt & primaryssl.crt into my keystore cacerts? Is this the problem?
I tried just installing the certificate.cer that I grabbed from Internet Explorer, but maybe this is the wrong approach?
I still get the error:
Error Detail
Unknown host: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
OK. For anyone who comes across this issue, instead of having to spend several hours pulling your hair out, I managed to get the connection to work:
This is taken from the following link:
https://groups.google.com/forum/#!topic/lucee/BPm8vYdgkPQ
Thank you Dominic Watson
I've just tried this and got it working:
Log in to Lucee server admin and navigate to "SSL Certificates"
Enter your host name "establishmindfulness.com" in the Host field (without the quotes)
Hit "list" button
Hit "install" button
That's it. The cfhttp call started working.
I'm running R on a Windows machine behind a corporate proxy. When running R 3.3.2 and version 2.3 of the curl package, this works:
curl::curl_fetch_memory("https://google.com")
Also note the following:
> curl::curl_options(filter = "sslcert")
sslcert sslcerttype
10025 10086
However, this is what happens when running R 3.4.1 and curl 2.8:
> curl::curl_fetch_memory("https://google.com")
Error in curl::curl_fetch_memory("https://google.com") :
error setting certificate verify locations:
CAfile: /mingw32/ssl/certs/ca-bundle.crt
CApath: none
Note:
> curl::curl_options(filter = "sslcert")
proxy_sslcert proxy_sslcerttype sslcert sslcerttype
10254 10255 10025 10086
I gather from the curl source code that these two new options were added in between these two versions.
Since this is the only relevant difference that I can find, my hunch is that curl is looking for the proxy_sslcert in the wrong path. But I can't figure out how to change that variable, nor what I should change it to. Also, what are the numbers shown (10254, etc)?
I don't actually need to use curl specifically, but a lot of other packages rely on it, e.g.
> httr::GET("https://google.com")
Error in curl::curl_fetch_memory(url, handle = handle) :
error setting certificate verify locations:
CAfile: /mingw32/ssl/certs/ca-bundle.crt
CApath: none
I am having problems getting RCurl function getURL to access an HTTPS URL on a server that is using a self-signed certificate. I'm running R 3.0.2 on Mac OS X 10.9.2.
I have read the FAQ and the curl page on the subject. So this is where I stand:
I have saved a copy of the certificate to disk (~/cert.pem).
I have been able to use this very same file to connect to the server using python-requests and the 'verify' option, and succeeded.
curl on the command-line seems to be ignoring the --cacert option. I succeeded in accessing the website with it after I flagged the certificate as trusted using the Mac OS X 'Keychain Access' app.
RCurl stubbornly refuses to connect to the website with the following code:
getURL("https://somesite.tld", verbose=T, cainfo=normalizePath("~/cert.pem"))
This is the output I get:
* Adding handle: conn: 0x7f92771b0400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 38 (0x7f92771b0400) send_pipe: 1, recv_pipe: 0
* About to connect() to somesite.tld port 443 (#38)
* Trying 42.42.42.42...
* Connected to somesite.tld (42.42.42.42) port 443 (#38)
* SSL certificate problem: Invalid certificate chain
* Closing connection 38
When I tested both curl with the --cacert option and the RCurl code above in a Linux VM with the same cert.pem file and exact same URL, it worked perfectly.
So equal tests on Linux and Mac OS X, and only on Mac OS X do they fail. Even adding the certificate to the keychain didn't work.
The only thing that does work is using ssl.verifypeer=FALSE, but I don't want to do that for security reasons.
I'm out of ideas here. Anyone else have any suggestions on how to get this to work?
You can try:
library ("RCurl")
URL1 <- "https://data.mexbt.com/ticker/btcusd"
getURL(URL1,cainfo=system.file("CurlSSL","cacert.pem",package="RCurl"))
Coming back to this issue I just wanted to point out that if you are still using RCurl, you should be using httr (which uses curl) instead.
I have confirmed that using config(cainfo="/path/to/certificate") with httr connections will work as intended.