Possible bug: login page through repo list with private repos and a custom home page path
(1) By anonymous on 2021-08-25 12:25:18 [link] [source]
I'm successfully serving multiple repos with fossil server --repolist and have taken them all private in the admin UI meaning a login is required. This works perfectly with the default homepage but breaks when you specify a custom pathname for the home (index) page that isn't /home/ because it fails to append the baseurl correctly.
For example assume the server was set up to have a bunch of *.fossil files in a directory and you were serving these with fossil server --repolist and --baseurl https://example.com/repos/ (assume also there's a reverse proxy providing the ssl and redirecting /repos/ and all children urls to a running fossil server). This of course means a page titled Repository List listing all the *.fossil files will exist at https://example.com/repos.
The problem comes when you decide to take one or more of these repos private AND to define a custom path for the home page. If you click on one of those private repos, let's assume a repo called project_one, on the Repository List page you'll end up on a login page looking something like https://example.com/repos/project_one/login?g=/repos/project_one/home and logging in will redirect you correctly to that page (/repos/project_one/home/). However if you go into the admin configuration page and instead change /home to be something else e.g. /timeline then, IF you click on the private project from the Repository List page, the login url will look like https://example.com/repos/project_one/login?g=/project_one/timeline (note the second /repo/ has been dropped) and logging in will redirect you to an unfound/404 page (specifically you will, when logged in, be redirected to https://example.com/project_one/timeline instead of https://example.com/repos/project_one/timeline).
Obviously you can still access the repo by simply using the correct url and a simple workaround is to just stick whatever you want to serve in the wiki page location the home page expects to look at so it's not a giant issue. I could probably also use the existing redirect option in the admin config to fix it though that's not ideal as linking someone to e.g. the timeline page when they aren't logged in has the same issue that after login they'll be presented with the 404 error page.
Apologies if this is poorly explained or is an error on my end but I can't see where it's going wrong.
(2.1) By Richard Hipp (drh) on 2021-08-25 13:12:05 edited from 2.0 in reply to 1 [link] [source]
Please try applying the fix shown at check-in 3571c8715d512a28 and report back whether or not this resolves your issue. Thanks.
(3) By anonymous on 2021-08-25 13:15:04 in reply to 2.1 [link] [source]
Thanks for the (very) quick response, I'm currently busy with work but I'll be able to try this in a few hours and will report back then.
(4) By JamLad on 2021-08-25 14:56:23 in reply to 2.1 [link] [source]
Hello, same user but now with an account.
That fix works for logging into the repo with the custom home page path but logging out from that repo now redirects to a non-existent page, it seems as a result of appending the entire home page path to the end of the url i.e. assuming again a custom home page at https://example.com/repos/project_one/timeline it successfully logs in and redirects but after logging out you end up here: https://example.com/repos/project_one/https://example.com/repos/project_one/timeline Everything else seems to work fine when logged in (which was also the case with the previous bug: it was just login redirects affected and logging out with the previous version did not result in an invalid url).
Additionally there seems to be a new bug for one of my repos that does NOT have a custom home page (i.e. sticks to the standard /home) where logging in now redirects to the server path and logging out is the same as above. In other words assuming the second repo wihout a custom home page path is located at https://example.com/repos/project_two (and thus home is https://example.com/repos/project_two/home as is standard) then logging in results in this url: https://example.com/repos/project_two//repos/project_two/home. As with above logging out results in https://example.com/repos/project_two/https://example.com/repos/project_two/home. Also as above all pages unrelated to login and logout work fine.
Apologies about the delay.
(5) By Richard Hipp (drh) on 2021-08-25 16:49:15 in reply to 4 [link] [source]
Another patch is now on trunk. Please try the latest.
(6) By JamLad on 2021-08-25 17:08:24 in reply to 5 [link] [source]
Both login and logout now work correctly for the repository with the custom home page.
The repository without a custom home page path still redirects to (the equivalent of) https://example.com/repos/project_two//repos/project_two/home on login but on logout it correctly comes back to the home page.
(7) By Richard Hipp (drh) on 2021-08-25 23:47:44 in reply to 6 [link] [source]
Please try again with the latest trunk check-in and report any new problems that you find.
(8) By JamLad on 2021-08-26 09:11:43 in reply to 7 [link] [source]
The latest version seems to have fixed all the bugs I noted previously for both types of repo (with and without a custom home page). If we find any more issues I'll post them as well but for now all is good.
(9) By Florian Balmer (florian.balmer) on 2021-08-27 12:00:35 in reply to 8 [source]
I may have found something related to this issue, with these steps to reproduce, in the Fossil Forum:
- View any forum thread, and click "Reply"
- On the "Reply As Anonymous?" page, click "Login"
This will land you on a "Not found" page, with a URL similar to:
(Note the double slashes.)
(10) By sean (jungleboogie) on 2021-08-27 13:17:32 in reply to 9 [link] [source]
I thought I had encountered something like this but I didn't know how to reproduce it or see the problem again.
Had you visited the login page directly, you wouldn't have seen this.
Thanks for tracking this down.
(11) By mistachkin on 2021-09-15 20:06:20 in reply to 9 [link] [source]
This should now be fixed on trunk.
(12) By Florian Balmer (florian.balmer) on 2021-09-16 06:51:26 in reply to 11 [link] [source]
Thanks. In case this is a reply to post (9), I think the problem reported there has already been fixed by check-in [c717d2803e].