xilph Posted March 10, 2009 Share Posted March 10, 2009 I maintain a website for my employer with a CMS (Joomla *sigh*.) We have an application that is licensed with a key/unlock code. Currently when a customer makes a purchase they call in with their key code and they're given an unlock code to license the software. My employer wants to move this process to the web. Their concern is that letting this out online opens the process up to abuse. Specifically, that the function to generate unlock codes would be plainly visible (think javascript). I can hack out some php scripts, but I consider myself a total noob. I was under the impression that php was server side only and that there's no way for someone to actually read your code. Is that true? How can I write this thing to make it more secure? Is PHP the right choice here? Here's the basic idea: A customer orders the software and is given an order number which is also written to a mysql db The application generates a random key when it is installed Customer goes to website and enters the order number and key code If the order number exists and an unlock code has not been generated for it yet, then an unlock code is generated and stored in the db with their key code Link to comment https://forums.phpfreaks.com/topic/148694-is-php-suitable-for-this/ Share on other sites More sharing options...
redarrow Posted March 10, 2009 Share Posted March 10, 2009 and what else getting excited here , what the program any free copy's going. php can do this and yee it easy. most php programmers do what your saying to our selling script's everything you mention can do done easily. Link to comment https://forums.phpfreaks.com/topic/148694-is-php-suitable-for-this/#findComment-780789 Share on other sites More sharing options...
redarrow Posted March 10, 2009 Share Posted March 10, 2009 How can we help then. Do you want us to create your program or need help where? Please tell us what you dont understand to create this i dear please. Link to comment https://forums.phpfreaks.com/topic/148694-is-php-suitable-for-this/#findComment-780795 Share on other sites More sharing options...
xilph Posted March 10, 2009 Author Share Posted March 10, 2009 My question is: how do I make the code that generates unlock codes secure so that no one can clearly read it? My limited understanding of PHP tells me that this is not a concern, because the server never serves this to a user during an http request, rather it executes the code itself and the serves the results to the client. Is this assumption correct? Link to comment https://forums.phpfreaks.com/topic/148694-is-php-suitable-for-this/#findComment-780835 Share on other sites More sharing options...
redarrow Posted March 10, 2009 Share Posted March 10, 2009 No one can see php code throw a browser, the only time you see php code is when,the coder use bad .extension names. it also true you can encrypt the actual code that create the project. the code then can only be decoded via the coder that encoded it. you can also lock a complete project to a url. who offers all that the craters/helpers off php ((((www.zend.com (( grate programs..... Link to comment https://forums.phpfreaks.com/topic/148694-is-php-suitable-for-this/#findComment-780838 Share on other sites More sharing options...
redarrow Posted March 10, 2009 Share Posted March 10, 2009 This is the truth, does not matter what you do to protect any project, the point is, you got some sort of best security in place passable, for you to hide your keys. that it. php and 3rd party add on's provide good strong security. example of what to watch out for when designing a project. http://phpsec.org/projects/guide/ want to add one more thing, as you read well written php code your notice the use of preg_match() function is used a lot, that because validating any code to a specific set off rules works. Link to comment https://forums.phpfreaks.com/topic/148694-is-php-suitable-for-this/#findComment-780850 Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.