Support hosting wikijs at subpath
closed
Nick Savchenko
As far as I see, wikijs can only be hosted at domain root (http://wiki.example.com/). Would be cool if it could also be hosted at a subpath, like http://example.com/wiki/
S
Simon Meyer
We want to use Wiki.js only for our developers on a server that has no domain. We already use some other applications without any problems with a reverse proxy on this machine. Just sad...
Sam Berney
Quite frankly I'm shocked at this. I'm not a big company that has rules that don't allow this, I'm just a user with a private server that doesn't have time to set this up and doesn't want to buy another SSL certificate, or mess with letsencrypt. You should put this factoid about requiring a subdomain on the front page to save future users time.
Nicolas Giard
Merged in a post:
Allow to specify base for frontend
Alik Send
Allow to specify custom base for frontend to make wikijs work not only on dedicated domains, but also on existing domain under specified path (like mysite.com/wikijs)
Loren West
This is also a major impediment for adoption within my company. Unfortunately the effort was deemed too large, and the issue was closed.
For reference, large companies have different divisions for managing their public exposure - including certificate management, subdomain naming, and port forwarding. My company is a public company, and this department won't let me add a public subdomain for an internal tool. We're not in the wiki business, so this is not likely to ever be a public exposure option for us.
I like wiki.js and use it on my personal laptop, but until this feature is implemented, we can't use it at our company.
Alik Send
Loren West: You can upwote my request. The solution is simple - add
<base />
tag with configurable href to <head>
.Loren West
Alik Send: This would be true if URI references were relative, which they aren't. It actually is a big task if the core was built assuming absolute URI paths.
Nicolas Giard
Loren West: You know you can use an internal sub-domain right? It doesn't have to be public.
Nicolas Giard
Alik Send: It's not that simple. There's lot of logic server-side that would need to be changed as well.
Loren West
Nicolas Giard - True - this is not about the public/private issue, but the team that manages DNS for our company. They have given us authority to route within our workgroup.
The discussion is interesting because both of us think it's easy for the other to change, and unfortunately reality gets in both of our way :)
Alik Send
Nicolas Giard: I hope you will add this feature to one of future releases. Thanks for your product
S
Simon Meyer
Alik Send: I don't think they will. I'm looking for another wiki now...
Nicolas Giard
closed
Nicolas Giard
There's no plan to allow for subfolder installations. Use a subdomain instead.
Lars Solberg
Nicolas Giard: any reason for that? It might be a blocker for those who need it..
Nicolas Giard
Lars Solberg: Because it adds unnecessary complexity to the app. From path parsing, path permissions, links within content that must be rewritten + again if the subfolder changes, all assets must be prefixed, potential cookie collision with other apps to the sheer amount of extra github support tickets because of incorrect configuration in Wiki.js or their reverse-proxy.
Most support tickets for v1 were concerning the site url not being setup correctly, which would necessary for subfolder install. Something I'd rather not repeat with v2.
Unless someone can give me a really compelling reason against using subdomains, sub-folder installation will not be implemented for the foreseeable future.
Riccardo Sangiorgio
Nicolas Giard: I understand what are the problems. In my case I am already using a third level domain to host the application and I cannot add a fourth level domain or add another third level domain because due to my provider they are not free. Now I have to switch to another wiki platform (sadly).
Loren West
Nicolas Giard: I have no choice in the domain:port selection at my company, and really want to use Wiki.js but can't until this functionality exists. Most features are nice to have, but this is a deal breaker for Wiki.js adoption at my company.
Brian
Nicolas Giard:
I realize this is an old thread, but I thought I'd share the steps I needed to take in order to implement a subdomain approach for our wiki-in-an-iframe proof of concept:
* request subdomain on internal intranet, obtain certs etc. for wiki.xxxxx.com
* relax Content-Security-Policy frame-src meta on all calling pages to include wiki.xxxxx.com
* expand cookie policy on cookies written by host site so that they would be delivered to wiki.xxxxx.com (cookie collision exposure?)
I think the subfolder idea has some merit.
Thanks for a great product.
h.ono
Nicolas Giard: I really wish for a sub path as well. We also try to use Wiki.js in an iframe and we have a basic auth on the page, which means embedding Wiki.js on another domain would trigger another basic auth and there's also another authentication for Wiki.js itself to login, which would be triple authentication to view pages allowed for that user in Wiki.js.
If it can be placed on a sub path, it would at least not pop up the basic auth for the second time.
DokuWiki could be put on a sub path and it also had basic auth pass through to login to the wiki with the basic auth user name which eliminated the extra 2 authentication which was handy.
You say it's complicated, but if you have a config parameter to set a sub path, the rest of the system has to follow that option to show things in the correct URL, even under reverse proxy.
Thanks for your consideration.
p
philip haugaard
Agreedo