Uploaded images are no longer able to be viewed in a IIIF viewer

[mejackreed]

Following #2203 images uploaded are no longer able to be viewed in a IIIF viewer. #2217 aimed to correct this by providing the host url protocol which works in many cases.

But if the application sits behind a load balancer, or other configuration where the controller.request.protocol != user protocol then this bug will still exist.

Also tracking here: https://github.com/sul-dlss/exhibits/issues/1442

[mejackreed]

A few options in mind for resolving:

1. Remove host and protocol parameters in the changed methods in #2203, #2217. For those who need custom hosts configured, use the Rails default_url_options

Which leads me to think, could this intended feature be supported by using default_url_options?

[mejackreed]

Experimenting with this, I'm not able to get this to work in the way I intended. I think this is because of the way that Rails url_helpers have expectations.

I was able to get a proof of concept working with reverting #2203, #2217 , and then doing something like the following in a Spotlight application's application.rb:

module CustomIIIFUrlOptions
  def default_url_options
    {
      host: 'www.example.com'
    }
  end
end

module SpotlightApplication
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 5.0

    # Settings in config/environments/* take precedence over those specified here.
    # Application configuration should go into files in config/initializers
    # -- all .rb files in that directory are automatically loaded.
    config.autoload_paths << Rails.root.join('lib')

   config.to_prepare do
      Riiif::ImagesController.send(:include, CustomIIIFUrlOptions)
      Spotlight::FeaturedImagesController.send(:include, CustomIIIFUrlOptions)
    end
  end
end

I'm not sure if this would cover all of the customizations that are needed. But right now does anyone have ideas to fix the current bug.. besides this?

@dunn Would something like this accomplish the surfliner needs?

[dunn]

I'm not sure I follow. How would default_url_options allow us to reroute IIIF urls to an external server?

[mejackreed]

@dunn for your example posted here: https://github.com/projectblacklight/spotlight/pull/2203#issuecomment-521801587

I could envision this doing something similar to below... which would yield IIIF urls likes this:

$ IIIF_BASE_URL="https://s3-us-west-2.amazonaws.com/my-iiif-stuff" rails s

https://s3-us-west-2.amazonaws.com/my-iiif-stuff/images/17/info.json id = 17 in the example.

Where the riiif routes would be mounted at /images (could be changed to foo ) and then custom additional hostname could be configured using the Rails provided customization in default_url_options.

# routes.rb
mount Riiif::Engine => '/images', as: 'riiif'

and

# application.rb
module CustomIIIFUrlOptions
  IIIF_BASE_URL = ENV["IIIF_BASE_URL"] || "localhost"

  def default_url_options
    {
      host: IIIF_BASE_URL,
      port: 443,
      protocol: 'https'
    }
  end
end

module MySpotlight
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 5.0

    # Settings in config/environments/* take precedence over those specified here.
    # Application configuration should go into files in config/initializers
    # -- all .rb files in that directory are automatically loaded.
    config.autoload_paths << Rails.root.join('lib')

    config.time_zone = 'Pacific Time (US & Canada)'

    config.to_prepare do
      Riiif::ImagesController.send(:include, CustomIIIFUrlOptions)
      Spotlight::FeaturedImagesController.send(:include, CustomIIIFUrlOptions)
    end
  end
end

[dunn]

Got it; I'll test that out and let you know if it works for us.

[dunn]

@mejackreed This seems to work; I'll poke at it a little more, though.

My remaining concern is that https://github.com/projectblacklight/spotlight/pull/2203 was meant to begin the process of decoupling RIIIF from Spotlight, so that eventually it could be an optional dependency. Is that something Stanford wants? From what I can tell the community consensus is that RIIIF should not be used in production, so to require a best-practices installation to do this sort of URL rewriting seems like a short-term solution at best.

[mejackreed]

With regard to riiif performance in Spotlight. We have been running riiif in production in Spotlight for years, and it has been working ok for us. I understand the riiif readme has the notion that it can't be run in production, but in our testing we have been able to setup production environments to effectively scale with riiif similar to other "production" iiif image servers.

A caveat here of course is that our primary riiif usage in Spotlight is for uploaded content which is not our primary image content in our Spotlight environment. But in analysis work done by @jcoyne, @cbeer, and others, they effectively replaced our infrastructure's primary image server with riiif with similar performance profiles as Cantaloupe and others once caching and concurrency were effectively optimized (as I understand it).

I like the idea of the decoupling from #2203 but with the problems we have seen arisen not sure of the best way to approach that now. It seems like for Spotlight to function (in its current state) it needs the following:

• IIIFification of uploaded images (either by riiif shelling out, or by another application)
• Support for IIIF url creation from these urls (relative or external)

I wonder if there is something we could do in riiif to make it more open to url customization for these urls? Where as it still has the notion and logic to generate correct IIIF urls, but maybe the riiif backend is not needing to do the tile generation. I'm thinking about something in a riiif initializer that just does this default_url stuff for us?

These are just some thoughts about the current status and perhaps maybe a future way forward?

Here is a proposal:

• Revert #2203, #2217
• Confirm that Surfliner can work with the default_url_options approach for now as a intermediary step
• Backport revert into a release with notes about the breaking change and the reasoning behind all of this
• Look into riiif enhancements which could make this change more adaptable and less of a monkey patch

[scottkushner]

I'm sorry, but isn't this a CORS issue? I'm getting the error: Access to XMLHttpRequest at 'http://xxx.xx.x.xxx/images/132/info.json' from origin 'http://xxx.xx.x.xxx:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. I'm running reverse proxy apache passenger with nginx stand-alone, and it seem to be a routing/cross-scripting problem between Rails and nginx. I'm trying to figure out how to configure rack-cors gem as an api helper with the routing, but haven't had success yet....or am I entirely off the mark?

[camillevilla]

@scottkushner I just cut a release that backports a resolution for this particular issue. If you're still running into this CORS issue, folks would be happy to troubleshoot on the #blacklight channel of code4lib Slack.