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.
