So the drama continues. Apparently all the issues that I have brought up are ‘cosmetic and not security related’ coding issues. I raised 5 different points, 2 of which they said they would implement (funny … since they are cosmetic) in the future. The other 3 (1 they just don’t get at all and the other two are up for debate in my opinion).

Cosmetic would mean, I didn’t like the ‘grey’ that they used in the header.. not the issues I brought up. Security related, even though some are mild, and I’ve stated that, are still security related.

So where does that leave me. I was presented with the ‘get the refund but can’t use the product or use the product but lose the full $97’ option again. I’ve stated in previous correspondence with them… keep your $97. I’ve modified my version of the code to address the issues I brought up and will use it. As presented in my earlier post, I said I was a unsatisifed programmer.. which led to me being a unsatisfied customer. No turning that around.. and sorry BANS if you think that was unfair. It’s my opinion and I have every right to state that. I’m sorry that you think I was pressuring you for a refund, but I felt the product didn’t meet my (the customer’s) satisfaction. I’ve never asked for a refund from a software vender EVER. I’ve never blogged about a software vender (in this way) EVER.

What I want to do is bring awareness with this blog, definitely off tangent from my initial launch mission. Now people can see that there could be issues, and take a close look before intalling it. The fixes are easy (from my perspective, and if applied from BANS side). If this is a kick in the pants to make things a touch tighter.. then cool.

Maybe, now I can get back to writing about code.

UPDATE:
One of my issues that I addressed (and said it was up for debate) was the ability of BANS to edit physical files directly on the file system with fwrite(). They pointed out to me that many other software application/venders use this (ie: WordPress). I was able to verify that WordPress does in fact do this and one of my favorite pieces of software, vBulletin, does this as well. I feel uncomfortable with this functionality because, if admin access would ever get compromised, a malicious user could overwrite files or add their ‘evil’ PHP to existing templates and execute those instructions. I think that is a bad thing, but obviously other venders don’t think it’s a big deal.. should I?.. hence the debate. I think it comes down to how secure the administrative access is. So for the record, I would like to concede my point about File System writing as one of the 5 items.

And I would like to offer ways to harden this section. If you have .htaccess ability you might want to consider limiting access to your IP or IPs (I understand if you have a dynamic IP or want the ability to administer from different locations, this might not be ideal). Another preventative measure would be to then add BasicAuthentication so you must log into get to the administrative directory (this would be a dual login then). This would also be done using .htaccess on that particular directory. The point is to prevent random anonymous attempts to circumvent access or brute force (make sure your BasicAuth pass is strong) their way into the administrative area. Why two logins? Because I trust BasicAuth.

I, myself, will add IP restriction for that area… as I do for other applications.