Allow passing of custom URL

[mhpob]

I'd like to suggest being able to pass a custom URL to be used when constructing manifests. I'm toying with running tiny.iiif via a Cloudflare tunnel, wherein it proxies my local network's IP and server's port (after adjusting for #13). The manifest retains this information:

{
  "@context": "http://iiif.io/api/presentation/3/context.json",
  "id": "http://192.168.0.129:8880/manifests/mf9rt8linf.json",
  "type": "Manifest",
  "label": {
    "en": [
      "test"
    ]
  },
  "items": [
    {
      "id": "http://192.168.0.129:8880/manifests/mf9rt8linf/canvas/lrnix4o2k0",
      "type": "Canvas",

If the domain at the end of the tunnel "xyz.com" it'd be nice to let tiny.iiif know this somehow so that the manifests are adjusted and they can be accessed external to my network. For example:

{
  "@context": "http://iiif.io/api/presentation/3/context.json",
  "id": "https://xyz.com/manifests/mf9rt8linf.json",
  "type": "Manifest",

[rsimon]

That's correct - the manifest will use the base URL you're using to acces the GUI. But you can actually change that base path, although it's not documented yet.

The gist is you'd have to create an .env file in the tiny folder and set a BACKEND_BASE variable. That will then override the base URL in the manifest.

That could probably made nicer in the future, pulling it up into the root .env file.

[mhpob]

Ah, yes. adding

tiny:
 ...
 environment:
   - BACKEND_BASE={base URL}

to docker-compose.yml does it!

[rsimon]

Perfect, I'll keep the issue open just as a reminder I need to add this to the docs. (And the variable could probably use a better name...)

[rsimon]

BTW: not sure if you are just toying with tiny-iiif out of curiosity (which is find of course :-) or building something that's going in production: but if it's the latter – and you can openly share it – I'd love to know more and, possibly, point people at it if you're ok with that. It would be the first actual "reference implementation", as it were. (I'm excited :-)

[mhpob]

My version of "production" would be geared toward maybe a dozen users and a couple dozen pictures... So with that scale in mind I think toying would be the best characterization.

My goal is to re-host (properly licensed!) aerial imagery and maps that aren't currently served using IIIF for use in tools like Allmaps. I'm not well-versed in IIIF and various tools, so this project lowered the hurdle enough for me to give it a shot!

Since it's a small project, I was planning to host it from my home server via a Cloudflare tunnel. It seems that this requires some edits to the nginx configuration and, given that the current project has some turnkey deployment, I would completely understand if this use case is too niche and out of scope.

[mhpob]

The endgame here for me is to let a local group I'm a part of georeference these aerials/maps for use in a separate tool where we geotag historic photos. So... Very niche use case.

https://yesterdays.maprva.org/

[rsimon]

Thanks for sharing the link – looks great! And feels "production" enough for me :-) (I'm in Digital Humanities, so everything I do somehow ends up being niche I guess ;-)

Most people will want (or have to) make changes to the default Docker or NGINX config, I assume. The included "turnkey deployment", therefore, is probably just a starting point in practice. The more I can learn about different practical setups, the better.

Just to confirm: with the current tweaks (docker port changes, NGINX default.conf fix, BACKEND_BASE variable) it does work for you, right? If so, I'll look into adding this to the docs.