Cannot expose webadmin in a subpath #297
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#297
Reference in new issue
Block a user
I would like to expose the webadmin site in a subpath instead of at the root, for example, at
http://example.com/znc/. This is currently not possible, as all assets and pages are refered to with absolute paths; for example, the CSS is expected to live at the root:Ideally, assets and pages would be referred to with relative URLs, or a
webrootvariables should be available for templates for building the URLs.This is possible by using "reverse proxy" techniques with your Web server. The specific configuration varies depending on HTTPd, but essentially you tell your front-end server to serve requests for a subdirectory from another "host". I haven't tested it, but I doubt that ZNC would have issues sending requests through an Apache or nginx front-end.
There might be some rewrite logic involved too (to catch resources and either rewrite the requests or rewrite the page source) but I am certain this can be done without any changes to ZNC.
Why I can't edit my comment on mobile, I don't know. Silly GitHub.
I am proxying the webadmin through nginx, using the newish
TrustedProxysetting. The issue is that assets and pages use absolute links; the only thing similar to what you are suggesting that I can find is http://wiki.nginx.org/HttpSubModule, but it seems to be too simplistic.In my opinion, some configuration option to set the web root for the links would facilitate things. That is the approach that, for example, Redmine uses.
The following is a draft of a possible way forward:
Changing the base uri to
+ m_Template["BaseURI"] = "/irc/";makes assets and links be requested from the subpath; but, for example, redirects are still directed to the/root.All in all, I think the best way is to offer a
BaseURIsetting, and makeOnPageRequeststrip it,Redirectprefix it and change the templates to either explicitely prefix the links with it or use the<base>approach in the above diff.Does it make sense?
I am sorry for the spam. The
OnPageRequestis not needed, as the reverse proxy is already stripping it, and theRedirectshould also not be needed, as http://wiki.nginx.org/NginxHttpProxyModule#proxy_redirect should be able to deal with that.What do you thing of the approach above?
I would be careful of using
<base>as it modifies the default behavior of links: http://stackoverflow.com/q/1889076/5991Modifying the templates to explicitly prefix the links is probably the better approach. Is there a possible use case where one server would want to have, say, a different
BaseURIfor each Web-enabled Listener?As an issue, this is duplicate of #138 (which was at some point turned into a pull request)
But that pull request isn't complete (e.g. it misses all those
href=changes); if you make this work, it would be great.Well, depends on the what the use case for having multiple listeners is. I guess the answer is yes: if you want to have listeners on different interfaces/ports, there is no reason to have them exposed via some same subpath.
About the
<base>, yes, should probably use the<? VAR BaseURI ?>prefixing each URI, instead of making them relative.@DarthGandalf, I don't know how I missed that issue. What do you think of the issue raised by @dgw? The commit you pointed at assumes that the prefix is global. Should it be per-listener?
I have seen that there is a
CHTTPSock::SetDocRootmethod. Do you think that we can implement a solution at that level?Per-listener sounds good.
DocRoot seems to be directory on file system, which limits access for statically served files. E.g. to protect /etc/passwd. And it doesn't seem to be used o_O
I won't be working on this soon, but will post any updates.
Best regards.
This is a design question.
The URIPrefix can be different for each listener. The plan is to add a member variable
m_sURIPrefixholding it. The issue is how to let theCWebSockknow about it.a) CWebSock accepts the URIPrefix as a constructor argument. In this case CIncomingConnection would receive it as an argument in the constructor as well and would pass it to the CWebSocket constructor.
b) Sockets, both IRC and HTTP, receive the listener that accepted them as a constructor argument. This way they have the listener settings available from the socket. This can be useful for various modules; for example, WebAdmin needs to know which one is the current listener in order to prevent the user killing it. In my view, it is sensible for the sockets to know which listener has spawned them.
I am missing something? What do you think?
"b)" looks more extensible, yes. Webadmin now compares only port number to understand that.
But it would add a dependency loop CWebSock->CListener->CWebSock
On the other hand, ZNC is already a mess from OOP point of view :-( Probably CIncomingConnection should use abstract factories of socket classes instead.
With regards to the previous question, I'm going with route "b)". I don't see the dependency CListener->CWebSock: the listener knows about the listener socket (CRealListener), but once the connection is accepted, no trace of the spawned socket seems to remain on the listener.
I will post a pull request during the day showing the approach, and would appreciate comments and code review.
Right now, the biggest block is that I don't seem to be able to get a template variable's value from within a loop. The case is, I want to change the lines from:
into:
but, although the
URIPrefixis defined in the outer scope, it seems not to be available inside the loop. How can I make it available.CListener->CRealListener->CIncomingConnection->CWebSock
"->" means "creates" in this case, the name of class is directly used in
functions of the other class
And it's not "although", outer scope is not accessible from inner scope,
right. Not sure why, but that's by design (probably it was just easier
this way). At least, in other places where inner scope needs access to
outer scope, the needed vars are explicitly copied to inner scope in .cpp.
08.02.2014 12:42, uu1101 пишет:
I see how AddModLoop fills all needed variables for each row, but those loops are constructed entirely in .cpp. CSSLoop and JSLoop rows are added via ADDROW directly in the templates; I don't see how can I stuff the URIPrefix there via .cpp.
I have created a pull request with current status of the change, and would appreciate any comments.
It looks like you can use a variable from the outermost scope:
<? VAR Foo TOP ?>See https://github.com/znc/znc/blob/master/src/Template.cpp#L812 and how it's used in existing stuff.