Can ARI be moved to a VirtualHost?

I’m trying to move ARI to a VirtualHost so that users who get vm web access can’t just back up to the maintenance area and start hacking.

It seems to partially work but I end up with other problems. Can this be done or is there another php app out there that would allow me to install ARI on a separate server?

Mike

I can’t believe that not one person in these forums doesn’t know how to do this???

no - it requires direct access to the voicemail file as well as the callmonitor spool file

There must be a way around this? I can’t believe that everyone is allowing direct access to their servers.

mlewis,
you asked a question, there is the answer.
There is always a way around it, modify the program so that you can enable remote access of the required files - but you are not going to do that in its current implementation.

That is what I asked. If you can’t help, why are you bothering to reply? Just to give me grief? I got it already, can’t be done as is, got it, believe you. I’m sure others have done it, I’m hoping to get their feedback. If you’ve not needed to do this, then no big deal, but I don’t want to give direct access to the machine, if I don’t have to.

PS: I’m looking for either an open source or commercial solution to this. I’ve seen countless posts from folks looking for the same solution.

Thanks.

Lighten UP Dude!!!
Just put a strong password on the maintenance functions and don’t sweat it…

Bill/W5WAF

As if, that’s a recipe for disaster. I don’t want to give public users direct access. Giving anyone access to ARI gives them access to hacking the root of the site.

I’m sure others are offering public services as well so this is something others must have or are dealing with.

If its really important, you could put a bounty out for someone to develop it for you, and you could donate it to FreePBX. It is possible that someone has already done this - but you were told that it can’t be done in it’s current implementation from FreePBX, along with the reason why. It wasn’t the answer you (or I for that matter) was looking for, but it was helpful.

I don’t know how bullet proof you need this. How about if you set the document root to the recordings directory, and also used the rewrite engine to try and circumvent any other stuff.
Another idea:
You could have that voice mail virtual host on port 80, and have the rest of the thing on a different port. Just some more ideas for you.

Yes, I did try the VirtualHost thought but there seems to be something missing. It partially works but I’m sure needs access to various files in the root of the server. Perhaps virtual paths if not too many are needed.

For public access, if you want a seriously protected system, do not rely on standard protections. Use a VPN. OpenVPN is a good answer to those problems and will give you a millitary grade protection. Then behind it you could use standard Apache / FreePBX protections.

Using a VPN give you the possibiity to revoke user keys (certificate revocation list), and to define the validity dates of each generated key.

I would never open the web interfaces of Asterisk / FreePBX to the world as they have not been writted neither intensively tested by security specialists.

For example, during more than one year the ARI web interface had a bug (reported since some monthes) in the URL encoding preventing normal use of the play audio voicemail. This has been only corrected recently. This show clearly the low level of trust we can have from some parts of the FreePBX project when it goes to security.

For public access, if you want a seriously protected system, do not rely on standard protections. >Use a VPN. OpenVPN is a good answer to those problems and will give you a millitary grade >protection. Then behind it you could use standard Apache / FreePBX protections.

Way too complicated for end users. I solved this problem in a very simple way thanks to some input from another thread.

I set up a front end realm which users have to log into first, from there, they enter their ext/password.
I used a virtualhost so that users can’t back up and start hitting to top page. Maintaining users is as easy as a text file or RADIUS list, etc.
The only folks who get the name/password are customers and they still have to enter their ext/password but at least can’t hack away at the root.

I agree about not wanting to give them direct access, that’s why I posted asking about this. The virtualhost method is a perfect solution.

Works like a charm :).

Mike