projectblacklight / spotlight

Spotlight enables librarians, curators, and others who are responsible for digital collections to create attractive, feature-rich websites that highlight these collections.
Other
161 stars 64 forks source link

Uploading a masthead image on an https site #2547

Open mcritchlow opened 4 years ago

mcritchlow commented 4 years ago

We've encountered the following issue with our Spotlight exhibits at UCSB and UCSD. This only happens in deployments setup for https/tls.

Steps to reproduce:

  1. Create a new exhibit
  2. Navigate to Appearance in the Exhibit Dashboard
  3. Select Exhibit masthead tab
  4. Select the 'Upload an image' radio button
  5. Browse and select an image.
  6. Note that no image is loaded into the leaflet cropping tool. Instead, looking at the dev tools console, one sees something like this:
application-a3a408b70f20a4dab526b7afc3d2d951cdd2667cc804e5b23062618e3f58bca8.js:4 Mixed Content: The page at 'https://spotlight-stage.library.ucsb.edu/starlight/chrissy-rissmeyer/appearance/edit' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://spotlight-stage.library.ucsb.edu/images/431/info.json'. This request has been blocked; the content must be served over HTTPS.

So it appears that the upload/request for masthead images is somehow missing the https protocol assignment for the info.json URL.

We're curious if others have encountered this and worked around it via existing configuration options, or whether this might be a bug.

cbeer commented 4 years ago

Is your production application possibly behind a proxy? It sounds to me like a misconfiguration between server layers, so Rails doesn't know to use HTTPS?

Take a look at e.g. https://stackoverflow.com/questions/26068752/rails-application-behind-proxy-with-ssl-renders-paths-as-http and/or https://api.rubyonrails.org/classes/ActionDispatch/SSL.html, and see if any of those might apply to you/fix the issue?

mcritchlow commented 4 years ago

@cbeer - Perhaps I should have mentioned that elsewhere in the application I see other spotlight and riiif related urls correctly getting the https protocol assigned. This is the only place we're seeing this. I have tried enabling force_ssl on our site, and it did not seem to address this particular issue. Though it seems like an omission that we weren't setting this already.

I'll take a read through what you wrote though, I think both we (UCSD) and UCSB might have reverse proxies for our staging/prod environments. thank you!

mcritchlow commented 4 years ago

@cbeer - Just wanted to follow up with a bit more info. We've still yet to identify where we might fix this on our end..

We've tested this with a few environment combinations:

We aren't using config.force_ssl in either environment, although I tested with it in both. In the VM it seemed to make no difference in the value set for the iiif_tilesource in the database for masthead image uploads. In k8s/puma we ended up with issues since Puma isn't setup to do ssl termination, so things like healthchecks failed. So I never got far enough to see if it makes a difference in that context. (Sorry if that's TMI)

In both cases, images uploaded via the masthead/js uploader are getting a iiif_tilesource set in the database as http://..../info.json instead of https://.../info.json.

In the DB, I see a mix of content for mastheads:

irb(main):007:0> Spotlight::FeaturedImage.where(type: "Spotlight::Masthead").pluck(:iiif_tilesource)
D, [2020-08-05T21:21:29.545284 #116] DEBUG -- :    (2.5ms)  SELECT "spotlight_featured_images"."iiif_tilesource" FROM "spotlight_featured_images" WHERE "spotlight_featured_images"."type" = $1  [["type", "Spotlight::Masthead"]]
=> ["", "https://exhibits.ucsd.edu/images/23/info.json", "https://exhibits.ucsd.edu/images/217/info.json", "http://exhibits.ucsd.edu/images/1446/info.json", "http://exhibits.ucsd.edu/images/1445/info.json", "http://exhibits.ucsd.edu/images/1457/info.json"]

If anything strikes you as wrong/misconfigured on our end, I'd be interested in your thoughts. Otherwise we'll keep at it. Thanks again.