Skip to content

Images in e-mail notifications are being 302 redirected instead of loading correctly

Problem description

We first noticed this 7 days ago. Prior to that, images in notification e-mails have loaded without any problems. But since then, no images are showing up anymore!

Here is an example from an e-mail notification I received from gitlab@mg.gitlab.com today:

image

Notice that the did not get loaded in the e-mail. The same note loads perfectly (including image) when viewed from the web UI:

image

In Gmail (my e-mail client), the img tag appears like this:

image

Removing the Gmail proxy prefix of the URL, I am left with the original img src:

image

... which I confirmed by viewing the "Show original" message source:

...<img src=3D"https://gitlab.com/simplechurch/simple-church/uplo=
ads/95db5606386145ed0d41172971ce7b89/Screen_Shot_2022-07-06_at_9.27.36_PM.p=
ng" alt=3D"Screen_Shot_2022-07-06_at_9.27.36_PM" data-canonical-src=3D"/upl=
oads/95db5606386145ed0d41172971ce7b89/Screen_Shot_2022-07-06_at_9.27.36_PM.=
png" class=3D"gfm" style=3D"max-width: 100%; height: auto; margin: 0 0 8px;=
"></a>

The decoded source for the img tag in the e-mail body is simply this:

<img src="https://gitlab.com/simplechurch/simple-church/uploads/95db5606386145ed0d41172971ce7b89/Screen_Shot_2022-07-06_at_9.27.36_PM.png" >

Minimal repro

When I pasted that into a simple HTML document (to remove Gmail from the equation), and loaded the page in a browser, this is the behavior that was observed:

  1. image — The image does not load
  2. image —
    In the Network tab, you can see that the GitLab server responds with a 302 redirect instead of a success response
  3. The full request/response HTTP logs:
    image

Compare that request/response to this request/response for a successful image load, when the same image is requested from the issue page:

  1. image
    [cookie content elided]
    image

Possible explanations

What differences between the working and non-working HTTP request could account for one working and the other not? The only headers that I noticed being different were:

  1. non-working:

    sec-fetch-site: cross-site

  2. working:

    cookie: ...
if-modified-since: Thu, 07 Jul 2022 02:29:07 GMT
if-none-match: "3c09af3986d48967a20800508704164b"
referer: https://gitlab.com/simplechurch/simple-church/-/issues/251
sec-fetch-site: same-origin

I tried copying and pasting the curl command for the working request and removing the if-modified and referer headers: it still succeeded in downloading the .png image.

The only remaining header that could explain the difference, then, is the cookie.

I don't know if my e-mail client was sending a cookie with the request before, but it seems like it shouldn't require a logged-in cookie to view the images, right? Because that would only even be possible for webmail, and only if signed into GitLab on the same browser as you are checking your e-mail — non-web-platform clients would not even have a gitlab.com login cookie available to send.

The only possible explanations that I can come up with, then, for what may have changed between a week ago and now:

  1. GitLab didn't use to require you to be signed-in in order to access gitlab.com/project/uploads/*.png images (it used to allow anonymous unauthenticated access) before, but has changed so that now it does require a login cookie in order to access them
  2. My Chrome browser got updated and now has some kind of stricter cookie blocking enabled by default that now prevents it from sending the gitlab.com cookie with the image request?

The first explanation seems like the most likely to me, but I can't go back in time and test that hypothesis now.

Can someone confirm whether this has changed recently? And if so, can you change it back please — or make it project-level security setting that can be disabled?

Possibly related issues

#31552 (closed), #24179