shiori: Unable to host under subpath

I’m trying to host shiori on port 7777 and then proxy pass https://localhost/shiori/ to that port, but when I do using this nginx config:

  location /shiori/ {
    rewrite ^/shiori/(.*)$ /$1 break;
    proxy_pass http://localhost:7777;
    proxy_redirect http://localhost:7777/ $scheme://$host/shiori/;
  }

I get this result:

This page isn’t working

And the URL shows:

https://localhost/login

Any ideas? Seems like shiori redirects to / (root).

Manually going to localhost/shiori/login brings up a broken login page, seemingly without both css, images, etc (can’t click on anything).

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 18 (5 by maintainers)

Commits related to this issue

Initial support for subpath #39 — committed to go-shiori/shiori by RadhiFadlillah 5 years ago
Fix: now cookie set per subpath #39 — committed to go-shiori/shiori by RadhiFadlillah 5 years ago
fix login problem when shiori is served behind rev-proxy and subpath When shiori is served in subpath cookie in login page is stored with wrong path, i.e. when root is set to /shiori, cookie path is ... — committed to KarolBedkowski/shiori by KarolBedkowski 3 years ago

Most upvoted comments

Guys, I’ve implemented this in 99d2793. To use it, config your proxy (in this example I use Caddy) like this :

your-awesome-domain.com {
    proxy /shiori localhost:9000
}

Then run shiori serve with webroot flag set like this :

shiori serve -p 9000 --webroot /shiori

By the way, the webroot flag will change the entire API route to be prefixed with the specified root. For example, by running command above now the index is located in localhost:9000/shiori instead of localhost:9000.

RadhiFadlillah on Oct 7, 2019

proxy_redirect only rewrites headers (eg Location), shiori redirects to /login, hence your should be proxy_redirect / $scheme://$host/shiori/; for the login page to redirect properly.

However this will not work with assets requested directly eg /css/,/js/ etc unless a rewrite is used .eg. for location ~ ^/(css|js|api) to /shiori/, which I don’t think would work well.

The issue also applies to caddy if the proxy isn’t root, and a rewrite to for all request isn’t used. e.g.

proxy /shiori http://localhost:8080 {  
        without /shiori                 
}

Possible fix: adding a webroot flag for server cmd so that it can be used for paths, serve -webroot shiori this would need changing of asset sources in html files + redirects to include the webroot variable.

peteretelej on Mar 11, 2018

If anyone’s still interested, I think I found the source of the issue. path.Join trims the trailing slash if the path isn’t / (see aa339d7706ef42b977f574bb77dee1c2ee3a1734)

NBonaparte on Apr 19, 2020

PR #374 sent. As suggested by @davidnewhall, logging in on by default, but can be turned off with --log=false at the command-line if necessary.

efrecon on Feb 18, 2022

Fundamentally, access logs on web servers should never be disabled by default. Recommend log rotation by default.

davidnewhall on Feb 17, 2022

Now if only we can get that fix into the codebase. 😃 cc @deanishe

davidnewhall on Nov 5, 2020

I’m still having issues with this when using the docker image. After I login with --webroot set the browser gets stuck in an infinite redirect loop.

Reproduction case:

Run: docker run -p 9000:9000 radhifadlillah/shiori:latest shiori serve -p 9000 --webroot /shiori
Try to login on http://localhost:9000/shiori with default credentials and you will get a too many redirects error screen after a successful login.

If I remove the --webroot /shiori parameter then everything works as expected.

kimpers on Oct 12, 2019

Wow very nice this deserves a new release!

On Monday, October 7, 2019, Radhi notifications@github.com wrote:

Guys, I’ve implemented this in 99d2793. For example, says you have Caddyfile configured like this :

your-awesome-domain.com { proxy /shiori localhost:9000 }

Now you only need to run shiori serve with webroot flag set like this :

shiori serve -p 9000 --webroot /shiori

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.< https://ci6.googleusercontent.com/proxy/CLJs0DCbNvW0HGRFsVH98uMrm60ekrcajpNR-mlsKVfFrj9txzx0xhJPd34U4oLarQbQKdbfAOER7Oolh9Vb6_HkCrXSXvC6Mwr3Skk8wZ7TTB4wTsUvbY90Eiu5sLhnX5F2ijbkcfseqzWpQlnpeDJqJ6E56FlpIwD2kDS3wxKu1V_jRp7MjxpVM4JhEK5o-ega4oYthIwVhECbb00HekQChCW0SKS9n_1tFqDImw=s0-d-e1-ft#https://github.com/notifications/beacon/AASYZGHIPVODYYFJKRABNELQNLZ37A5CNFSM4ETMHC42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAPPXHQ.gif

– Raphael

ekianjo on Oct 7, 2019