Support local images

[fonnesbeck]

When I try to convert a slide deck, the images used in my markdown cannot be found by md2googleslides:

Unable to generate slides: Error: Invalid URI "images/PyMC3.png"

This is despite the images directory being in place in the current directory.

[erickoledadevrel]

The Slides API, and hence this tool, only supports publicly hosted image URLs at the moment. Changing this to a enhancement request.

[jakebiesinger]

It's perhaps beyond the scope of this project, but one option would be to upload the local files to Drive first, then have the imageUrl field refer to the Drive media view, with the access token embedded as a query parameter.

Using the same API in python, the code looks something like

# upload to Drive
response = drive_service.files().create(media_body=local_image_filename).execute()
url_with_auth = drive_service.files().get_media(fileId=response['id']).uri + '&access_token=%s' % credentials.token

slides_service.batchUpdate(body={'requests': [{
      'createImage': {
          'url': url_with_auth,
        }
      }]})

[erickoledadevrel]

Google Slides stores the original URL of the inserted images and exposes that data to collaborators, so that approach could lead to the access token being shared more broadly than desired. You could instead temporarily make the image world-readable, avoiding the need for the access token, but that isn't the most secure and not every G Suite user is allowed to share files outside their domain.

[sqrrrl]

Yep, have this change ready locally, but because the access token is leaked I need to find a different solution. Unless the Slides API changes to support specifying images by Drive ID instead of URL (have an open feature request for it,) all the other solutions I can think involve converting this into a hosted service. That has its own set of issues though and likely won't happen any time soon.

[jakebiesinger]

Got it. I hadn't realized that the url persists after the image is uploaded. I'm not familiar enough with Google's access tokens... I take it they persist for longtime? Can we request a shorter expiration?

Using a short-lived token seems slightly less-bad than temporarily making the image world-readable since you don't have to worry about domain restrictions on sharing publicly and the script's untimely death won't leave resources dangling in the wild.

[sqrrrl]

It is a short-lived token -- about 1hr. But still, it's still a bit too long and too risky to expose, particularly since there was a recent PR to allow custom templates and the full drive scope is needed for that. That token can be very powerful, even if just for that short period of time.

[jakebiesinger]

One hacky solution I'm playing around with:

1. Get a list of current collaborators
2. Revoke all permissions on the destination slides
3. Request a new OAuth token (and don't store it) -- separate from the "normal" one to do steps 1 & 2
4. Generate the slides
5. Revoke the OAuth token from step 3 (GET https://accounts.google.com/o/oauth2/revoke?token=..., no need to be logged in)
6. Restore collaborators

It's.... not pretty. @sqrrrl do you have a link to the open feature request in Slides API? This seems like such an oversight!

[sqrrrl]

I'm also considering using something like file.io, but am a little concerned about uploading data to a 3P. Maybe doable with an explicit opt-in (CLI flag --use-fileio), will see...

[sqrrrl]

Oooooh, found a nice little hack :)

Drive has a nice feature that if you try to download a file with the access_token in the query parameter, it redirects to a locked domain (ephemeral domain with auth encrypted and signed in the URL). That URL is safe to use since it's valid only for the particular file and doesn't directly expose the access token.

So logic becomes:

• Upload file
• Request download in client w/access_token but don't follow redirect
• Capture the redirect URL and use that in as the image source URL

Yay :)

[sqrrrl]

Previous mentioned hack isn't viable (can't rely on it long term.)

Ended up using https://file.io for ephemeral hosting with an explicit ack on the command line (--use-fileio). Fixed in master, will be in next release (0.5). Should get around to pushing that shortly.