I am setting up an auction site and have chosen phpprobid as the script. I know that no auction script is perfect, so I wanted to just go with something usable and then spend more time and money on a better site if the concept kicks off. However, part of the software is encrypted and I'm not sure I understand the implications. The below two files are encrypted. Would you know if this would be a problem if I need to build the site from scratch again (but be able to migrate users/auctions etc.)? /includes/init.php ? Software activation /includes/functions_security.php ? SQL sanitization and related security functions I'm not a programmer so plain english would really be appreciated! Thanks
If you're planning on modifying the software at any point you want to get a license that allows you fully access to all the code. It would be an extremely poor operational decision to start using some proprietary software that you figure out down the road you can't change to meet your needs.
The encrypted files initialize something (the site when you installed it? everything when a user connects to it?) and the security of the site. They have nothing to do with the users, auctions, etc. Except, maybe, for the way the passwords are encrypted. The worst that would happen is that your users would have to create new accounts on the new software, and you'd have to update the database to link the auctions to the new user_id, or reassign the old user_id to each user - it all depends on what the new site is going to look like (from a programmatic viewpoint). The best advice I can offer you is to find software you're going to keep using, or pay someone to write what you want. Since you're not a programmer, you're not going to rewrite the code yourself (unless you're prepared to spend a few years learning programming, security, finance, etc.), and no programmer you hire is going to want to spend a month or two of your money just learning phpprobid to the point that he can make a new site for you that uses the same data, in the same format, as the old one did (or, at least, uses data in a format that the old data can be converted to). That's called scut work and no one wants to do it. At least, not unless they get paid so much that they can take a year off on their new yacht once they finish. (You'll get offers here by people claiming that they can write your new site for $100, or some such ridiculous offer, but it's easier to just burn the money. At least you'll have some ashes.)
Thanks for your replies. I think the decoder sits on the server (ioncude php loader) which helps make the files work while on that server. I also understand that I can transfer to different servers, but the question remains about whether or not I can transfer the databases and users etc. In an ideal situation I would get someone to write what I want. I take your point about scut work, but am currently financially constrained and need to go with a feature rich package and just amend the skin. Once I've gotten proof of concept and some funding I can hire some inhouse programmers to work on the site - however, I need to just plan ahead of the curve and just make sure that when those inhouse programmers come in, they do not inherit a platform which they cannot modify (because of those two files) and cannot even create a different platform because they can't migrate the files. I guess the things I need to transfer would be the databases, usernames/passwords etc (anything else?). In the case of a rebuild, I think cost for transferring would not be an issue as I would have got funding if the concept is proven. But I need to just check that structurally the site is not built in a way that I am held hostage to the phpprobid platform because of those two files (the words SQL sanitization gets me nervous) A few specific questions: . Does SQL sanitization means that I can't access my database without phpprobid's help? . Rukbat - to your worst case scenario, is there a quick way to check that now and see if that will be a problem? But I think that even in that scenario, I can keep the user IDs tied to the auctions, but reset all the passwords and get new passwords generated and sent to emails/cell phones right? . I am planning a mobile app in the future. Do you know if these two files prevent that sort of development?
It could also mean business logic and anti-piracy code are inside these encrypted files. SQL sanitization means to clean the input from user to prevent SQL injection. You can still access the database without phpprobid's help, via 3rd party scripts.
The database (the users are in the database) has nothing to do with whether some of the PHP code is encrypted. You'd need an experienced programmer to tell you that. He'd have to look at the structure of the database, and the structure of the program, and tell you whether it's easy, difficult or "hold your left elbow in your left hand" to write a program to use that data. As I said, usernames and passwords are in the database. Are the passwords encrypted? (They should be.) Then, is the code to encrypt them encrypted? If so, your users are going to have to be given new passwords when you start running the new version, and change them to what they want. That usually just means that the user input is 'cleaned up' so that the site isn't subject to a SQL injection attack. That's trivial stuff, and has no effect on the database (except to ensure that what's in it is clean data). No - see above. Well ... As I said, that could be a lot of scut work. If the user_id is an autofill field, the auction table's user_id field would have to be updated to the new user_id for each auction. Lots of stuff like that. It takes the training of a high school freshman to understand the work, but there can be days, or even weeks of it. And there may be other data updating needed. That depends on the mobile app, and how you want to do it (and how the site is written). As I said, I don't know phpprobid. If it's templated, you can write mobile templates, and redirect mobile users to those pages. Or if the site is really designed correctly (Deathshadow, where are you when we need you?), it'll just flow properly for a mobile browser. Or someone may have written a mobile plugin. Lots of questions, but most of them can't be answered without at least some work. Can you eventually move the site to better software? Definitely. Anything in software can be done - all it takes is enough experience (on the part of the developer) and time (which means money you can spend). Can someone write Facebook from scratch? Sure - that's how it was done. But not overnight and not on the cheap. Don't worry about the encrypted files. A good programmer will look at the results they achieve and write code to achieve those results. Will the code be exactly the same? Almost certainly not. Will the site work the same? Yes. (I recently wrote a module for a forum to replace one that I could have bought, but was encrypted. I don't like running code I can't understand, and I can't read encrypted code. Does it do the same job? Yes, and better.) Run the site, save the profits and, if the concept works, hire someone to modify phpprobids to do it your way, or to write a whole site from scratch using the existing data. My take, though, is that you're competing with eBay, and I've seen sites try that and fail. I've never seen a site succeed against them.
When you buy a php software package, this is the way the seller protects your accessing the software and either changing it to bypass licensing if it is locked to your site. It "phones home" and verifies the license.
Your right - encryption does not phone home, the encoded php does. That's why it is encrypted. I was just talking from experience. Several large php packages that I purchased had some of the modules encoded with ioncube. I suspect that the (long) license key had the purchasers url encrypted into it. When the software was installed the license key was entered and stored in the mySQL data base. Each time the software was started it checked in/phoned home to verify the license. The php code at the sellers site simply decoded the license key and compared that with the referral url/site that the code was running on. When I tried to move the code to another site it would not run and gave an error of a license violation. When I asked the package vendor I was told that I would need to "upgrade" to run it on a different host. If I had had direct access to the php, it would have been easy to simply comment out the relevant code. I spent several days trying to break the ioncube encryption or develop a work around and finally gave up and paid the additional licensing fees to run on the other server. In the process I learned a lot about ioncube and php encryption. More than I ever wanted to know. So the php and the license key were both encrypted to make a secure licensing system. There were enough other php modules encoded that I could not determine the logic of the program to bypass the license. I did not have any luck decrypting the license key either. Sorry I gave the wrong impression... Of course, the other reason to encrypt php code is simply to hide the source code.
Maybe some particular encrypted PHP you had did that, but the vast majority of PHP encrypting is just to keep the end-user from seeing the code and from changing it.
Thank you all (especially Rukbat) for your help on this. I understand this better now and have some comfort. Just curious (and may seem like a dumb question since I'm totally new to this forum) - are you all programmers for hire as well? I understand that you're not cheap, and it may be a longshot (if Rukbat is right that auction sites are doomed to fail) - but there are some really smart people here that could qualify if I do succeed.
I can't answer for all of us, but I've been earning my living writing computer code for the past 40 years, the last 20 of which has been mainly dealing with databases and web apps.
In my experience, encrypting it does nothing more than slow it down and upset your customers. I don't recommend it. All software gets pirated. However, intelligent people never run NULLED software. Running your own code on your own site encrypted... pointless. And yes, Rukbat is very smart and gives valid advice.
You're making me blush. It's not "smart", it's "old". I've been doing this stuff longer than a lot of programmers have been converting oxygen into carbon dioxide. It's not that I never make mistakes, it's that I've already made most of them (more than once) and (finally) learned from my errors.
PHP encryption is a method of obfuscating scripts in such a way that it offers additional protection and prevents unauthorized editing of the scripts. mcrypt.* and mdecrypt.* provide symmetric encryption and decryption using libmcrypt. Both sets of filters support the same algorithms available to mcrypt extension in the form of mcrypt.ciphername where ciphername is the name of the cipher as it would be passed to mcrypt_module_open().