My company would like to be able to mask the URL of the PBX Manager. What I mean by this is that typically when you are using it, the URL will be something like http://www.somesite.com:10000/asterisk/edit_user_vm.cgi?usr=100 whereas we would like it to only display the http://www.somesite.com portion of the URL.
I'm fairly certain this is possible, but I'm not 100% sure how to do it. I was hoping someone here with some more experience might be able to shed some light on the subject.
Thanks!
Devand MacLean
Cloud-Phone Inc.
We had tried using frames
We had tried using frames previously, but were encountering an issue where when the user would try to log in it would not spit them out an error but it would not let them through. It would just appear to refresh the page, and would not let them log in. Do you know why that might happen?
I also tried creating a symlink between /usr/libexec/webmin/asterisk/ and /usr/libexec/webmin/test/ and browsed to https://www.somesite.com:10000/test/ and it said that the user root was not permitted to use that webmin module. After enabling it inside of the root user's webmin user, I tried again, and it said that our license was not verified. When I attempted to reinstall our license under /test/ it did not accomplish anything, it still said that our license was not verified.
I have been clawing through using apache rewrite rules for the past few days. They are incredibly cryptic, but I'm starting to wrap my head around them. Do you think you might be able to point me in the right direction as to how I could accomplish this with rewriterules?
Thank you!
Further to the comment above,
Further to the comment above, what I have tried is adding the following to the end of the file /etc/httpd/conf/httpd.conf
RewriteEngine on
RewriteRule asterisk/(.*)$ /phones/$1 [PT,L]
After restarting the httpd service (/etc/init.d/httpd restart) and browsing to the page https://www.somesite.com:10000/asterisk/index.cgi it still displays the /asterisk/ portion in the browser as opposed to /phones/
I used the htaccess tester at http://htaccess.madewithlove.be/ to validate my ReweriteRule, and it says that with that input URL it should output https://www.somesite.com:10000/phones/index.cgi but it clearly is not. I am obviously missing something, likely something very basic and obvious.
Any ideas?
have you tried RewriteEngine
have you tried
RewriteEngine on
RewriteRule ^/(.*)$ https://www.somesite.com:10000/$1 [P]
or something similar? asterisk doesnt run on port 10000, thats webmin.. asterisk is going to have to be the proxy connection to your port 10000 content.
So, I did end up getting it
So, I did end up getting it to work. Sort of. I am able to make it so that you can browse to www.somesite.com/pbx/ and it displays the content from www.somesite.com:10000/asterisk/
I used mod_proxy and 2 Apache RewriteRules. I have pasted my additions to the httpd.conf file below
ProxyPass / http://localhost:10000/
ProxyPassReverse / http://localhost:10000/
RewriteEngine on
RewriteRule ^/pbx/(.*)$ /asterisk/$1 [L,PT]
RewriteRule ^/asterisk/(.*)$ /pbx/$1 [R=301,NS,N]
What it does, is if you browse to /asterisk/ (which is where the login page sends you by default after logging in), it redirects you to /pbx/, and then subsequently when you browse to /pbx/, it rewrites it as /asterisk/ to the server. On the last line, the NS option is critical. It tells apache not to follow this rule for any internal subrequests.
The one thing I am not able to do is make it run over https://. In fact, I am not able to make the Apache server serve -anything- over https on this box.
Any suggestions?
actually that makes sense...
actually that makes sense... because if you were to actually proxy https, you'd be a man-in-the-middle which ssl is supposed to prevent.
Well, that part of it might
Well, that part of it might make sense, but I still can't even serve something as simple as https://www.somesite.com/asdf.txt without mod_rewrite or mod_proxy doing anything to it.
The weird thing is that I -am- able to do this with other servers that I have deployed, and I can't seem to find any differences in the two configs.
What I think I could do to work around this (if I could get the server to serve via https://), would be to proxy from the DocumentRoot of https://www.somesite.com/ to http://localhost:10000 and just make it so that the only whitelisted IP is 127.0.0.1
Would that work? And any ideas why I can't serve files over https://? Might it be because I have the "ProxyRequests On" and/or "RewriteEngine On" directives set in my httpd.conf?
Also, from the little I have read on the SSLProxyEngine directive, shouldn't it be possible to proxy between the DocumentRoot of https://www.somesite.com/ and https://localhost:10000?
hmm thats an iteresting
hmm thats an iteresting idea..
lock down webmin to only localhost, turn off encryption, then proxy the whole thing from your SSL engine of apache? Let me know if it works, the logic seems sound.
So, I've got it working quite
So, I've got it working quite nicely actually. The following directives need to be added (assuming you have your SSL all properly configured). Note, that you can replace "/pbx/" with "/anythingelse/" and it will change the new trailing directory for the pbx manager URL.
I've also added a little to the end of httpd.conf that redirets any requests to http:// to the same URL using https://
Let me know what you think! :)
==// /etc/httpd/conf.d/ssl.conf
RewriteEngine on
RewriteRule ^/pbx/(.*)$ /asterisk/$1 [L,PT]
RewriteRule ^/asterisk/(.*)$ /pbx/$1 [R=301,NS,N]
==// /etc/httpd/conf/httpd.conf
ProxyPass / http://localhost:10000/
ProxyPassReverse / http://localhost:10000/
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteCond %{REMOTE_ADDR} !=^127.0.0.1$
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L,NS]
==// /etc/webmin/miniserv.conf
ssl=0
allow=127.0.0.1
==// /etc.webmin/config
referer=1
I'm a results-oriented guy...
I'm a results-oriented guy... if its working then I think thats pretty awesome. just curious, where you trying to obsfuscate the fact that you were running asterisk? Its going to show up in the sip messages if someone were to take a real look at the packets.
Yes, we are trying to mask
Yes, we are trying to mask the back-end technology. Anyone who knows enough could still figure it out if they tried hard enough for sure, but we were more interested in the average user's experience. The majority if not all of our client base doesn't know enough about SIP (or care enough) to sniff their voice traffic for that information. If they did, they probably wouldn't need our service. ;)
you can use frames, you can use HTML redirects, or you can use rewrite rules in apache.