Default imgur key not working, causes problems with reprex

[camille-s]

Hi, I was doing some debugging of errors I got making a reprex (someone else reported tidyverse/reprex#475), and traced it back to how xfun::upload_imgur is used by the reprex package. It seems that the default key isn't currently working. I already set an environment variable with my own key, but to illustrate with the default one:

img <- xfun:::R_logo('[.]jpg$')
# default key from package docs
xfun::upload_imgur(img, key = "9f3460e67f308f6")
#> Error in xfun::upload_imgur(img, key = "9f3460e67f308f6"): Failed to upload /.../logo.jpg (reason: 1025)
# setting a key works
xfun::upload_imgur(img, key = Sys.getenv("R_XFUN_UPLOAD_IMGUR_KEY"))
#> [1] "https://i.imgur.com/J3oxXNv.jpeg"

On its own supplying your own key is fine, but passing an argument to it in the context of calling reprex::reprex or the reprex add-in requires a workaround with explicitly setting the upload.fun knitr option. My current workaround, in case it's useful to see how this looks downstream, is to set that option within the scope of what reprex knows about, either by including it in what's on the clipboard or the file reprex is sourcing:

knitr::opts_knit$set(upload.fun = function(x) {
    xfun::upload_imgur(x) # would supply key if it weren't in the envvar that upload function looks for
})
library(ggplot2)

dat <- diamonds[1:10,]
ggplot(dat, aes(x = x, y = y)) +
    geom_text(aes(label = cut))

Thanks in advance!

xfun::session_info("xfun")

R version 4.4.2 (2024-10-31)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 24.04.1 LTS, RStudio 2024.12.0.467

Locale:
  LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8       
  LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
  LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
  LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

Package version:
  graphics_4.4.2  grDevices_4.4.2 stats_4.4.2     tools_4.4.2     utils_4.4.2    
  xfun_0.50.3  

---

By filing an issue to this repo, I promise that

• I have fully read the issue guide at https://yihui.org/issue/.
• I have provided the necessary information about my issue.
  • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
  • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('xfun'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('yihui/xfun').
  • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
• I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

[yihui]

It appears that someone abused the default key recently. The error message I get from the imgur API with the default key is "Too Many Requests". Since the API call is anonymous, I have no idea who made the many requests or what were uploaded. Oddly enough, this key appears to have full credits at the moment:

> str(xfun::rest_api('https://api.imgur.com', '/3/credits', token = c('Client-ID' = '9f3460e67f308f6')))
List of 3
 $ data   :List of 5
  ..$ UserLimit      : int 500
  ..$ UserRemaining  : int 500
  ..$ UserReset      : int 1736838327
  ..$ ClientLimit    : int 12500
  ..$ ClientRemaining: int 12500
 $ success: logi TRUE
 $ status : int 200

If you want to provide your own key to reprex, you need to set it via either the option options(knitr.imgur.key) or the env var R_KNITR_IMGUR_KEY (instead of R_XFUN_UPLOAD_IMGUR_KEY) because reprex uses knitr::imgur_upload instead of xfun::upload_imgur.

[camille-s]

Thanks for looking into this so quickly, and for sharing your key for all this time. The more detailed error I get with reprex::reprex(std_out_err = TRUE) points to xfun::upload_imgur, not the knitr version, which is what pointed me in this direction.

(Edited with the new message from 60c3bb9)

This reprex appears to crash R.
See standard output and standard error for more details.

Standard output and error

Quitting from lines 20-25 [unnamed-chunk-2] (wax-mouse_reprex.spin.Rmd)
Error in xfun::upload_imgur(file, key, ..., include_xml = TRUE) : 
  Failed to upload wax-mouse_reprex_files/figure-gfm/unnamed-chunk-2-1.png (reason: Too Many Requests)

That's the same as the issue posted in the reprex repo linked above.

But I see now that that's because the knitr one wraps around the xfun one. Setting the envvar R_XFUN_UPLOAD_IMGUR_KEY works since it gets passed through, and can be read in the scope of the environment reprex::reprex creates.

Anyway, if the solution is for us ungrateful devs to register our own keys, that's more than fair! Just wanted to bring it to your attention & help think through workarounds, since right now it requires this extra hidden step.

[jennybc]

@yihui Do you think it's a coincidence that this has happened so near an xfun release? Just brainstorming, has anything changed recently about xfun in some sort of CI situation where running tests or examples could be consuming quota? I wonder if something about CRAN submission and checks is part of the story.

[yihui]

@jennybc I don't think it has anything to do with the recent xfun release. The default key has worked for more than a decade (at least no one has ever reported a quota issue). I'm sure it was still working last week, but I have no idea what happened from yesterday. I tried to register for a new key (https://api.imgur.com/oauth2/addclient), and it worked fine. I can definitely switch the default key to the new one.

[jennybc]

You might want to take some mild measures to obfuscate the key, just to make it a little more work for a robot-ish actor that's scouring github repos for a key to abuse. Historically we've done this with other API keys that aren't really sensitive but for which it's nice to minimize external, inorganic use.

[yihui]

Good point. Thanks for the tip!

[yihui]

I've added three new (obfuscated) keys and will use a random one each time. I feel the old key may have been banned by Imgur. By searching on Github, I can see a few PHP applications seem to be using it (so you are right that it has definitely been discovered by actors outside the R community).

For reprex to work again, I'll have to release new versions of both knitr and xfun to CRAN, or you provide a new key in reprex and make a new release.

[jennybc]

For reprex to work again, I'll have to release new versions of both knitr and xfun to CRAN, or you provide a new key in reprex and make a new release.

I suppose reprex might be one of the main ways people end up using xfun::upload_imgur(), but it's not the only way, yeah? I guess what I'm really asking is whether you feel any urgency around doing a release, in terms of knitr and related packages. If so, I'll just let this self-resolve.

But if it's going to be a while, I can do something in reprex.

[yihui]

I suppose reprex might be one of the main ways people end up using xfun::upload_imgur(), but it's not the only way, yeah?

I think so. I'm not aware of major usage of this function in other places.

I guess what I'm really asking is whether you feel any urgency around doing a release, in terms of knitr and related packages.

I can probably release knitr next week to resolve this issue.

[jennybc]

I can probably release knitr next week to resolve this issue.

OK thanks! Let me know if this ends up not working out and I'll do something in reprex.

[njtierney]

Hey just chiming in here to say thank you and also that installing the latest version of xfun solved this issue with reprex for me :)