Some questions for the devs

[The_Assimilator]

1. Why, at the top of every PHP script, do you do the following:

if (isset($_GET["user"])) {$user=$_GET["user"];}
elseif (isset($_POST["user"])) {$user=$_POST["user"];}

Wouldn't it be a lot easier (and cleaner) to get users to set register_globals = on in their php.ini, thus removing the need for explicit variable declarations such as these?

2. ViciDial uses "select *" almost everywhere when it would be easier and a lot more efficient to explicitly list the fields required, are there any plans to change this?

3. Alternatively, would it not make sense to use views and/or stored procedures to abstract some of this away? I know this would require MySQL 5+, but I can't think of any reason for people to still be using 4.x.

[mflorell]

Register globals on is not secure and it is not even an option in PHP 6, so we don't use it. Although I must say I miss it.

As for select *, it's not used everywhere, and with new functions going in we do specify fields. This is something that we will eventually get around to cleaning up hopefully before the 2.2.0 release. Doing tests it doesn't actually look like it causes much in the way of extra load so it hasn't been a priority.

Not using views and stored procedures was a design decision based on portability and the desire to remove that processing from the database into PHP and Perl which is easier to scale than a MySQL database. Also, we maintained MySQL 4 compatibility through the 2.0.5 branch.

[The_Assimilator]

Apologies if I sounded a bit critical in my original post, that wasn't my intent.

Thanks for the answers - I know about register_globals being deprecated but I haven't been keeping up with PHP for a while so I wasn't aware that v6 doesn't allow it at all.

Regarding "select *", would you guys accept patches for the instances where I've found these?

I understand the reluctance to use MySQL views (I've played with them a bit and they gave me some... interesting performance problems) and I guess that sprocs aren't really appropriate for ViciDial, as the code isn't doing anything esoteric with the DB.

However, one thing that worries me is the possibility of SQL injection in the PHP code. Are there any plans to address this in the future?

Finally, I have to congratulate and thank you for the ViciDial documentation - it's detailed, thorough and exactly what's needed for someone who's installing the system for the first time, which is a big (and extremely welcome) difference from the majority of open-source projects where documentation, if it exists, is either too technical or just plain unhelpful. That said, I'd appreciate some sort of technical reference on how ViciDial is structured, the reasons it was implemented as it is, etc.

edit: Another question, why is Asterisk 1.2 preferred for ViciDial, as opposed to 1.4?

[mflorell]

Yes we do accept patches against SVN trunk. You can post the diff files to the issue tracker.

We addressed the SQL injection attack issue years ago, this is why we filter all variables as they come into ViciDial to remove anything resembling an SQL fragment, except of course when we want to, like for FILTERS, but even then we don't allow complete statements.

I'm glad you like to documentation, and I wish I had more time to write documentation because there are many things that could be explained better than they are, but that's not always the top priority.

What kind of technical reference are you looking for exactly?

We recommend Asterisk 1.2 because it crashes less. 1.4.21.2 seems to work fairly well too, but we do recommend periodic scheduled reboots to help keep the system running during production hours.

[williamconley]

Also, the "1.4 seems to work fairly well" comment is a somewhat recent development. When the client boxes that have moved to 1.4 at the server cluster level seem stable enough ... I trust Matt to change the signal. We've got a couple clients on 1.4, but we're still a little cautious ourselves in that regard. At this point, I think it may be very soon that the wind changes and 1.4 will become preferred. Soon. But maybe not today.

At this point, I'm very willing to wait for Matt (with the number of servers he's overseeing) to announce that change. Those clients of mine who required 1.4 services have them, and seem happy with the transition ... and we've experienced very little recently in the way of difficulties, so I don't think it'll be that long.

[mflorell]

For new installs we have been doing more 1.4.21.2 installs than 1.2 installs. Mostly because zaptel 1.2 is not supported with newer Linux kernels.

We use about 5 patches to fix various things in 1.4.21.2, some of the patches are very new and we are still evaluating them for long-term inclusion.