Re: [R] Deprecating download method='wininet' in R on Windows causes trouble with corporate proxy
On Fri, Sep 30, 2022 at 01:27 Henrik Bengtsson wrote > Is R centrally installed? It usually (but not always...) is installed through a central install process, but installations will not be kept synchronized. (I.e., we end up having independent installations, many different versions, many different collections of packages (and versions thereof).) > If so, environment variables 'HTTP_PROXY', 'HTTPS_PROXY', and > 'HTTPS_PROXY_USER' could > be set for all users by setting them in the R_HOME/etc/Renviron.site file. Yes, this can be delivered centrally. The problem arises if and when the variables for the proxy must be adapted (e.g., proxy URL changes). I am toying with the idea to source, from the Rprofile.site, a central configuration file (specified as a UNC path). Then, if the values of the environment variables need to be changed, this is done once for all, and roll-out to users will be immediate. [...] > At least this avoid having to configure them in MS Windows settings, which is > tedious to document and explain. I fully agree! Thank you for your advice, Henrik! __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Deprecating download method='wininet' in R on Windows causes trouble with corporate proxy
Is R centrally installed? If so, environment variables 'HTTP_PROXY',
'HTTPS_PROXY', and 'HTTPS_PROXY_USER' could be set for all users by
setting them in the R_HOME/etc/Renviron.site file. R_HOME is the
folder where R is installed. You can find this file from within R by
calling:
> file.path(R.home("etc"), "Renviron")
[1] "C:/PROGRA~1/R/R-42~1.1/etc/Renviron"
If not centrally installed, I don't know anything better than users
setting them in their personal ~/.Renviron file;
> normalizePath("~/.Renviron")
[1] "C:\\Users\\alice\\Documents\\.Renviron"
For example,
> cat(file = "~/.Renviron", append = TRUE,
> "HTTP_PROXY=http://proxy-host:3128/;, "HTTPS_PROXY=https://proxy-host:3128/;,
> "HTTPS_PROXY_USER=dummy", sep = "\n")
At least this avoid having to configure them in MS Windows settings,
which is tedious to document and explain.
My $.02
Henrik
On Thu, Sep 29, 2022 at 3:48 PM Selke, Gisbert W.
wrote:
>
> Method="wininet" is deprecated and scheduled to go away, the standard method
> is now libcurl. This causes trouble for all R users in our shop, because we
> are sitting behind a corporate proxy, which uses Kerberos authentication.
> (We're all on Windows.)
>
> Using wininet, this used to work without problems and without additional
> effort; it currently still does with explicit method="wininet" (which, by the
> way, precludes use of the handy menu command "Update packages", which will
> use the default method, i.e., libcurl as of now.)
>
> For the future, when wininet will be gone for good, the only option we have
> is to resort to first setting environment variables HTTP_PROXY and
> HTTPS_PROXY and then tricking the proxy out of using Kerberos, setting
> HTTPS_PROXY_USER to a dummy string.
> This is certainly doable for R users with enough knowledge of the
> technicalities of internet access, but our average R user will just be lost.
> As has been pointed out elsewhere
> (https://github.com/rstudio/rstudio/issues/10163#issuecomment-1154071514) ,
> this will create a lot of blood, sweat and tears (and swears), and it is a
> moderate nightmare to maintain consistently and up-to-date for many users.
>
> My first question is: Since we are probably not the only institution in this
> situation, has anyone come up with a robust and maintainable solution other
> than our approach described above?
>
> Failing that: would it be possible at all to change the use that the R core
> makes of libcurl in such a way that it would automagically Do The Right Thing
> (tm)? In principle, this should be possible; after all, wininet did the
> trick, and ordinary browsers can handle this situation. (Disclaimer: I know
> nothing about the R internals so cannot say whether I am being overly naïve
> here.)
>
> Any help appreciated.
>
> (I'm new to this list, so if this has been discussed here before, I apologize
> and would be grateful for a pointer to do my reading.)
>
> [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[R] Deprecating download method='wininet' in R on Windows causes trouble with corporate proxy
Method="wininet" is deprecated and scheduled to go away, the standard method is now libcurl. This causes trouble for all R users in our shop, because we are sitting behind a corporate proxy, which uses Kerberos authentication. (We're all on Windows.) Using wininet, this used to work without problems and without additional effort; it currently still does with explicit method="wininet" (which, by the way, precludes use of the handy menu command "Update packages", which will use the default method, i.e., libcurl as of now.) For the future, when wininet will be gone for good, the only option we have is to resort to first setting environment variables HTTP_PROXY and HTTPS_PROXY and then tricking the proxy out of using Kerberos, setting HTTPS_PROXY_USER to a dummy string. This is certainly doable for R users with enough knowledge of the technicalities of internet access, but our average R user will just be lost. As has been pointed out elsewhere (https://github.com/rstudio/rstudio/issues/10163#issuecomment-1154071514) , this will create a lot of blood, sweat and tears (and swears), and it is a moderate nightmare to maintain consistently and up-to-date for many users. My first question is: Since we are probably not the only institution in this situation, has anyone come up with a robust and maintainable solution other than our approach described above? Failing that: would it be possible at all to change the use that the R core makes of libcurl in such a way that it would automagically Do The Right Thing (tm)? In principle, this should be possible; after all, wininet did the trick, and ordinary browsers can handle this situation. (Disclaimer: I know nothing about the R internals so cannot say whether I am being overly na�ve here.) Any help appreciated. (I'm new to this list, so if this has been discussed here before, I apologize and would be grateful for a pointer to do my reading.) [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
