starred/shiori

Fork 0

mirror of https://github.com/go-shiori/shiori.git synced 2026-04-25 14:35:52 +03:00

[GH-ISSUE #39] Unable to host under subpath #27

New issue

Closed

opened 2026-02-25 23:33:17 +03:00 by kerem · 18 comments

kerem commented

2026-02-25 23:33:17 +03:00

Owner

Originally created by @Necklaces on GitHub (Mar 3, 2018).
Original GitHub issue: https://github.com/go-shiori/shiori/issues/39

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).

Originally created by @Necklaces on GitHub (Mar 3, 2018). Original GitHub issue: https://github.com/go-shiori/shiori/issues/39 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).

kerem

2026-02-25 23:33:17 +03:00

closed this issue
added the
type:bug

priority:low

component:backend
labels

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@RadhiFadlillah commented on GitHub (Mar 10, 2018):

Hi @Necklaces sorry for late response.

I'm sorry, unfortunately I don't have any experience using nginx, so I can't give any advice. Usually I just use caddy since it served HTTPs by default.

If others has any advice or solution feels free to comment.

@RadhiFadlillah commented on GitHub (Mar 10, 2018): Hi @Necklaces sorry for late response. I'm sorry, unfortunately I don't have any experience using `nginx`, so I can't give any advice. Usually I just use `caddy` since it served HTTPs by default. If others has any advice or solution feels free to comment.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@peteretelej commented on GitHub (Mar 11, 2018):

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 commented on GitHub (Mar 11, 2018): `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.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@ekianjo commented on GitHub (Sep 23, 2019):

@RadhiFadlillah can you provide a fix for this issue as suggested by @peteretelej ? Right now it's not possible to host it on a subdirectory with nginx...

@ekianjo commented on GitHub (Sep 23, 2019): @RadhiFadlillah can you provide a fix for this issue as suggested by @peteretelej ? Right now it's not possible to host it on a subdirectory with nginx...

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@RadhiFadlillah commented on GitHub (Oct 7, 2019):

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 commented on GitHub (Oct 7, 2019): Guys, I've implemented this in [99d2793](https://github.com/go-shiori/shiori/commit/99d27930eaee84746fa3fc777201b4baa7738672). 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`.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@ekianjo commented on GitHub (Oct 7, 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 commented on GitHub (Oct 7, 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

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@kimpers commented on GitHub (Oct 12, 2019):

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 commented on GitHub (Oct 12, 2019): 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: 1. Run: `docker run -p 9000:9000 radhifadlillah/shiori:latest shiori serve -p 9000 --webroot /shiori` 1. 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.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@wangxu94 commented on GitHub (Dec 17, 2019):

I'm having the same issue as @kimpers above.

Reproduction:

Build shiori from source following the documentation here
Run: shiori serve -p 8082 --webroot /shiori --portable
Try to login on http://<server_url>:8082/shiori and got this error:
Set up an Apache reverse proxy with settings:

    <Location /shiori>
        Require valid-user
        AuthType basic
        AuthFormProvider file
        AuthFormLoginSuccessLocation /shiori
        AuthUserFile "/etc/apache2/passwd"
        AuthName "My Login"
        Session On
        SessionMaxAge 1800
        SessionCookieName session path=/
        SessionCryptoPassphrase <passphrase>
        ErrorDocument 401 /login.html
        ProxyPass http://localhost:8082/shiori
        ProxyPassReverse http://localhost:8082/shiori
        RequestHeader set X-Forwarded-Proto "https"
        RequestHeader set X-Forwarded-Port "443"
    </Location>

Get the same redirection error.

Everything works fine without the webroot option.

@wangxu94 commented on GitHub (Dec 17, 2019): I'm having the same issue as @kimpers above. Reproduction: 1. Build shiori from source following the documentation [here](https://github.com/go-shiori/shiori/wiki/Installation) 2. Run: `shiori serve -p 8082 --webroot /shiori --portable` 3. Try to login on http://<server_url>:8082/shiori and got this error: ![firefox_QEbqdkSC7L](https://user-images.githubusercontent.com/15028233/71041361-bfc9cc00-218d-11ea-9618-21c4510bb31c.png) 4. Set up an Apache reverse proxy with settings: ``` <Location /shiori> Require valid-user AuthType basic AuthFormProvider file AuthFormLoginSuccessLocation /shiori AuthUserFile "/etc/apache2/passwd" AuthName "My Login" Session On SessionMaxAge 1800 SessionCookieName session path=/ SessionCryptoPassphrase <passphrase> ErrorDocument 401 /login.html ProxyPass http://localhost:8082/shiori ProxyPassReverse http://localhost:8082/shiori RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" </Location> ``` 5. Get the same redirection error. Everything works fine without the webroot option.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@NBonaparte commented on GitHub (Apr 19, 2020):

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 commented on GitHub (Apr 19, 2020): 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)

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@davidnewhall commented on GitHub (Nov 5, 2020):

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

@davidnewhall commented on GitHub (Nov 5, 2020): Now if only we can get that fix into the codebase. :) cc @deanishe

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@Systemsemaphore commented on GitHub (Nov 12, 2020):

+1, I need this. Currently using binary shiori-linux-amd64-stretch

@Systemsemaphore commented on GitHub (Nov 12, 2020): +1, I need this. Currently using binary `shiori-linux-amd64-stretch` ![error_unknown_flag](https://user-images.githubusercontent.com/74195074/98971184-2035ca80-2511-11eb-80a6-3460322c91ac.png)

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@rbdevr commented on GitHub (Nov 22, 2020):

hello all,

I'm trying to run shiori behind apache.

shiori - http://localhost:5000/shiori

shiori serve -p 5000 --webroot /shiori

apache - http://myserver/shiori

<Location "/shiori">
Require all granted
ProxyPass http://localhost:5000/shiori
ProxyPassReverse http://localhost:5000/shiori
</Location>

I'm getting the following error:

"
The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

This problem can sometimes be caused by disabling or refusing to accept cookies.
"

Are you guys working on this issue?

Cheers

@rbdevr commented on GitHub (Nov 22, 2020): hello all, I'm trying to run shiori behind apache. shiori - http://localhost:5000/shiori shiori serve -p 5000 --webroot /shiori apache - http://myserver/shiori `<Location "/shiori">` ` Require all granted` ` ProxyPass http://localhost:5000/shiori` ` ProxyPassReverse http://localhost:5000/shiori` `</Location>` I'm getting the following error: " The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies. " Are you guys working on this issue? Cheers

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@KarolBedkowski commented on GitHub (Jan 17, 2021):

Hi,
Cookie with session id has wrong path when shiori is served under subpath.
Above patch solve problem.

@KarolBedkowski commented on GitHub (Jan 17, 2021): Hi, Cookie with session id has wrong path when shiori is served under subpath. Above patch solve problem.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@stale[bot] commented on GitHub (Feb 10, 2022):

This issue has been automatically marked as stale because it has not had any activity for quite some time.
It will be closed if no further activity occurs.
Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 10, 2022): This issue has been automatically marked as stale because it has not had any activity for quite some time. It will be closed if no further activity occurs. Thank you for your contributions.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@efrecon commented on GitHub (Feb 16, 2022):

I have a fork that contains the fix from @NBonaparte above, and also generates an access log. I fixed the github workflows so they generate packages named after the organisation and repository hosting the project (i.e. not hardcoded to go-shiori/shiori). In other words: Docker images are available within my fork if you wanted so.

These are "good to have" changes. @fmartingr would you accept a PR?

@efrecon commented on GitHub (Feb 16, 2022): I have a [fork](https://github.com/efrecon/shiori) that contains the fix from @NBonaparte above, and also generates an access log. I fixed the github workflows so they generate packages named after the organisation and repository hosting the project (i.e. not hardcoded to `go-shiori/shiori`). In other words: Docker images are available within my fork if you wanted so. These are "good to have" changes. @fmartingr would you accept a PR?

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@efrecon commented on GitHub (Feb 16, 2022):

On a side note: I noticed that this is marked with a note:fixed?, but this isn't fixed entirely until what @NBonaparte proposed and/or the content of my fork is taken in.

@efrecon commented on GitHub (Feb 16, 2022): On a side note: I noticed that this is marked with a `note:fixed?`, but this isn't fixed entirely until what @NBonaparte proposed and/or the content of my fork is taken in.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@fmartingr commented on GitHub (Feb 17, 2022):

These are "good to have" changes. @fmartingr would you accept a PR?

Of course! This has to be one of the issues with the most activity, so if this is a requirement for you folks I will gladly accept a PR with the fix. The access log seems useful too, but it has to be optional (default to false) so people can avoid filling storage with it if they don't want to.

@fmartingr commented on GitHub (Feb 17, 2022): > These are "good to have" changes. @fmartingr would you accept a PR? Of course! This has to be one of the issues with the most activity, so if this is a requirement for you folks I will gladly accept a PR with the fix. The access log seems useful too, but it has to be optional (default to false) so people can avoid filling storage with it if they don't want to.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@davidnewhall commented on GitHub (Feb 17, 2022):

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

@davidnewhall commented on GitHub (Feb 17, 2022): Fundamentally, access logs on web servers should never be disabled by default. Recommend log rotation by default.

kerem commented

2026-02-25 23:33:17 +03:00

Author

Owner

@efrecon commented on GitHub (Feb 18, 2022):

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 commented on GitHub (Feb 18, 2022): 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.

kerem referenced this issue

2026-02-25 23:33:20 +03:00

[GH-ISSUE #67] Add automatic Docker build #44

kerem referenced this issue

2026-02-25 23:34:31 +03:00

[PR #27] [CLOSED] Dockerfile + README.md usage #496

kerem referenced this issue

2026-02-25 23:34:33 +03:00

[PR #66] [MERGED] Extended docker support #507