vinny42

Indeed, all the code that handles the response is loaded on the browser, so the system cannot depend on anything the client does. But, don't underestimate scriptkiddies and the people with no social life, they will happily invest days to hack it, just to be able to say they did. If money or other prizes are involved this gets even worse.

The script in the cron can ado everything that PHP can do, including seoind request to any server, incuding your server because it's just another server.

I don't understand what you mean, this starts a script that does whatever you program it to do. How you start the script doesn't change what the script does.

True. I guess the question is a bit too obvious because how can you register a player's moves in a game if you can't identify the players individually? And if you can identify the players then you can also identify non-players. Then the only problem remaining is how do you identify a cheating player (which will be 98% of your problems)

Actually, all you know then is that a particular sessionid was supplied. If you want to know that the dat came from a particular browser you have to try to identify that browser, whch iy can't because all you have is what the browser tells you, and all of that can be spoofed, except for the IP, but the IP is not necessarily unique to a browser and with mobile devices they can even change while browsing. But, identifying the browser is a separate issue, the real problem is making sure that the data that you receive is legit, and not faked by a hacker (who can also login legitimately)

It's the only way.

Yes, see: crontab on un*x, or windows scheduler.

Like I said four times: you cannot do this in PHP code, you must write a binary library to plug into PHP. And I understimated xdebug, it can create these logs too: http://devzone.zend.com/1135/tracing-php-applications-with-xdebug/ and as you can see from that, the logs are *huge*, there are thousands of lines in each log and like I said; if the script goes into a loop you can easily get millions of lines of executed code. You are simply never going to make that visible.

That's the problem with browser-based games; a hacker can see exactly what you are sending back and forth so you can't prevent them from trying to modify the messages your game sends to the server. You can try to add things like a checksum to make creating false messages more difficult, but in the end your HTML5 code can be read and modified completely. This is why browserbased games usually let the server keep track of the important events, using the browser only as a way of interacting with the player. Then the worst a player can do is automate the response and be really quick, but he cannot for example submit an illegal highscore, or select an option that the server doesn't allow.

ZendStudio uses a binary plugin for PHP that hooks into PHP itself, so you cannot do this unless you also write a plugin in C++ and compile it and load it on the webserver. My point is: you cannot make the log readable, there is simply too much data to make it understandable.

That's not really what happens. Sessions are identified by the sessionid which is stored in a cookie. By default, the cookie is setup to be forgotten when the browser closes, but this can be easily reconfigured at scriptlevel and serverlevel. A few years ago I had the curiuos problem that sessionid's were being re-used on the same browser; opening and closing forgot the cookie but visiting the page produced the exact same sessionid again. As long as the sessionid is different, which PHP tries to guarantee by no issueing sessionids for which there is already a file on disk. If the cookie doesn't delete, or the sessionid is stored in a URL, it's perfectly possible to use the same session on many different computers at the same time. Depending on what you want to do with the data it might even be a good idea to use a database, so you don't lose any data when people abandon the quiz before it's completed. (this can be important to know; if many people leave the quiz at the same question then that question may be offensive to them or the quiz may simple break and not allow them to answer). Also, for testing, look into Selenium. That's a sort of recorder that can record and playback a browsing session, and check the content of a page while doing it. That allows you to record filling out the quiz and later test if the quiz still works as it did when you recorded it. It saves you from having to go through the entire quiz manually just to see if a change in the final page looks ok.

I can't read spanish. I understand what you want to do; log the execution of a script line by line so you can debug the script by looking at the log. ZendStudio can do this and the logs are *huge* because if you go into a loop of twenty lines, that executes 500 loops, you get 10000 lines in your log, which makes it unreadable. This is why xDebug aggregates the results and only tells you how many times each function was called. This is much more usefull information than a full line-by-line log. If you want to know which lines are executed it is also much more usefull to use a breakpoint and step-through the code. So yes I understand what you want an no you can't do that and you porobably shouldn't anyway :-)

Ah, so you are sending a proper HTTP request through some network device? Or are you sending the data through some serial cable? The string you posted in your first post can be parsed with parse_str(), no problem. But you may want to look at $_POST too, perhaps PHP is already picking it up properly.

That looks like URL data, which you can parse with parse_str(). See: http://www.php.net/manual/en/function.parse-str.php

Sessions are identified by the sessionid. generally the sessionid is stored in a cookie and security rules don't allow you to set a cookie for domain X from domain Y. However, there is nothing to stop you from making the browser send the sessionid in the URL, from where PHP can set the cookie, making the same sessionfile availably on both domains.

Indeed. Use your database for what it's good at; create a table that has the exact columns of the CSV and use LOAD DATA INFILE to fill it with the CSV data. Then use separate queries to copy the data from that table to your actual database. This way you can check if the CSV has loaded correctly without having to parse the data, and you can easily manipulate the data where needed. (like remove duplicates, find empty fields, etc) The reasing behind this method is that you can use one query to check/change all records. If the data in the new table passes a handfull of sanitycheck queries, you're good to import it for real.

I quickly typed this up. All it does is pretend to load a gallery from a database which can either be mongodb or postgresql. At the bottom of the script you'll see a "router" class that looks at a GET parameter to select mongo or PgSQL. The way it makes this selection is to first create a galleryhandler and then inject an instance of a storagehandeler into it. The galleryhandler only knows how to talk to a storagehandler to load and save a galery, and the storagehandler only knows how to load and save a gallery to a postgresql or mongodb database. The injection is done through composition; a set() method pushes an instance of the storagehandler into the galleryhandler and this works because all storagehandlers have the same methods for loading and saving. As you'll see, the PostgreSQL version returns some dummy data and the mongodb version throws an exception, to prove that you are really accessing the different storagehandlers only by injecting them. Key things to notice are that the galleryhandler only knows that it should as "the storage handler" to load a gallery, it does not care how the storagehandler does it's work, it could access a database it could read tealeaves, the galleryhandler doesn't care. So, you are free to write any kind of storagehandler and composite it in. I wrote this very quickly so feel free to comment/ask/curse at it. <?php /** * Class gallery, only holds the data of a gallery. * */ class gallery { /** * @var */ private $_strName; /** * @param $pStrName */ public function __construct($pStrName) { $this->_strName = $pStrName; } } /** * Class dbPgSQL * * This class only knows how to run queries against a PostgreSQL database and to return the results. * */ class dbPgSQL { /** * Pretend that a query is being executed against the database and return a fake resultset * in the form of an array. * * @param $pStrQuery * * @return array */ public function executeQuery($pStrQuery, $pArrParameters) { return array(array("name" => "mygallery")); } } /** * Class dbMongoDB * * This class knows how to run queries against a MongoDB database. */ class dbMongoDB { /** * * @param $pStrQuery * * @return array */ public function executeQuery($pStrQuery, $pArrParameters) { Throw new exception("Not implemented"); } } /** * Class galleryStorage_PgSQL * * The gallerystore for postgresql knows which queries to run to get which part of the gallery data back. * It uses composition to keep a copy of a dbPgSQL() class inside it to run the queries through. * */ class galleryStorage_PgSQL implements interface_galleryStorageHandler { public function __construct() { /** * This is a hard dependency, which would normally be done using some injection but that fogs up the image * I'm trying to paint here. */ $this->_objDatabaseAccess = new dbPgSQL(); } /** * * GetGalleryByName runs a query to get gallerydata for the supplied gallery name. * * @param $pStrName * * @return gallery */ public function getGalleryByName($pStrName) { // Go to the composited database class database // and ask ir for the correct record. The dbPgSQL class should take care of SQL escaping etc. $arrData = $this->_objDatabaseAccess->executeQuery("SELECT gallerydata FROM database WHERE name=:name", array('name' => $pStrName)); // Return the first record that was found (this is purely for demo purposes) return new gallery($arrData[0]['name']); } } /** * Class galleryStorage_MongoDB * * The mongodb version of the gallery storage class. * It knows how to get a gallery out of a mongodb database */ class galleryStorage_MongoDB implements interface_galleryStorageHandler { /** * @param $pStrName * * @throws Exception */ public function getGalleryByName($pStrName) { throw new Exception('MongoDB is not implemented yet'); } } /** * Class interface_storageHandler * * Defines which methods a gallery storage handler must implement. */ interface interface_galleryStorageHandler { /** * @param $pStrName * * @return mixed */ public function getGalleryByName($pStrName); } /** * Class galleryHandler * * The gallery handler knows how to use a gallerystorage to fulfill the requests that the application will give to it. * Note that the galleryhandler does not know which of the two storage handlers it has been given. * As long as the object in $pObjStorageHandler follows the interface_galleryStorageHandler, it's ok. * */ class galleryHandler { /** * @var interface_storageHandler */ protected $_objStorageHandler; /** * @param $param */ public function setStorageHandler(interface_galleryStorageHandler $pObjStorageHandler) { $this->_objStorageHandler = $pObjStorageHandler; } /** * @param $pStrName * * @return mixed */ public function getGalleryByName($pStrName) { // Call the storagehandler to return the gallery. No clue which storagehandler it is, don't care, // as long as it returns a gallery. return $this->_objStorageHandler->getGalleryByName($pStrName); } } /** * Class router */ class router { /** * */ public function route() { // Create a galleryhandler because all this routine does is get a gallery. $objGalleryHandler = new galleryHandler(); // If the URL contains "?command=gomongo" then the mongodb version of the storagehandler // is injected into the galleryhandler, otherwise it will use the PgSQL one. $strCommand = ''; if (isset($_GET['command'])) { $strCommand = $_GET['command']; } switch ($strCommand) { case 'gomongo': $objGalleryHandler->setStorageHandler(new galleryStorage_MongoDB()); break; default: $objGalleryHandler->setStorageHandler(new galleryStorage_PgSQL()); } echo '<pre>'; // Make the galleryhandler return a gallery $objGallery = $objGalleryHandler->getGalleryByName("poo"); // Make it visible. var_dump($objGallery); } } $objRouter = new router(); $objRouter->route($_SERVER['REQUEST_URI']);

A backtrack can't go back indefinately, there is a limit to how many calls you can see, and even then you have to count them manually. It's either going to be xdebug, wich also won't trace indefinately, or Zend Studio, which costs a bundle. With xdebug and netbeans you can at least see what you code is doing by stepping through it. Perhaps you should tell us a bit more about what you are trying to see in this information?

Look for xdebug, that can generate code-coverage reports that tell you which lines have been executed. But, it's much more useful to use an IDE like phpstorm or netbeans, then you can start a stript and pause it to see where what the scripts is doing, and step through the script line by line and see what all the variables etc contain.

You could try javascript: http://stackoverflow.com/questions/3102889/javascript-autosubmit-form and yes, just typed "javascript form autosubmit" into google :-)

That's probably good enough; if a hacker can get far enough into your system to get that salt, you've got much bigger security holes than the password :-)

None of the above, because they can all be predicted by the hacker. Just like he/she can probably predict that your salt will be prepended or postfixed to the password... The salt should be different for every user, otherwise finding one password means finding the salt and and finding the salt means you can create a new rainbox list and you'll have found a lot of other passwords aswel.

What Barand typed; The aliasses my1 and my2 define two subsets and the LEFT JOIN merges them together.

Perhaps the most important thing to keep in mind is the single-responisibility principle: each class does one thing. So you would have one class for holding the userdata, one class for storing the data in the the database, one class for presenting the data to the user, etc. What I usually do is something like this: userclass - only holdfs the user's data, it has no functionalitiy other than validating it's own data to see if the object is in a sane state. userhandler - knows which operations can be done on/to/with a userobject. userstorageMySQL - knows how to store a userobject in a MySQL database. userstoragePgSQL - knows how to store a userobject in a PostgreSQL database. dbMySQL - executes queries on a MySQL database dbPgSQl - executes queries on a PostgreSQL database When I want to load a user I instantiate the userhandler and do a "loadUserById(42)". The userhandler only knows that loading a user requires an instance of a "userstorage_*" class and the current configuration tells it if that's a MySQL or PostgreSQL database. A factory class then creates for example a userstorage_PgSQL instance which sends queries to a dbPgSQL instance to execute the queries that actually gets the data from the database. The userhandler then receives the data and fills a userobject with it and returns the object. The point of this mountain of classes is that you can replace any of the lower classes with anything else as long as the method calls are the same. (@see: interface, design by contract) The userhandler class uses "a" storage class. What that storage class does internally is completely hidden from the userhandler, so you can replace it with a MySQL-based object or even a mock object for testing, the userhandler will never know or care. I make all these classes work together by using composition. My userhandler has a property that I can fill with an instance of a storageclass and the storageclass has a property for an instance of a dbclass. So the storageclass is *not* an extension of a dbclass, and the userhandler class is not an extension of the storageclass. Does that shed any light on the subject?

In database you must learn to think set-oriented. You are looking for a set of records where it is true that the value of each student appears in the subset for this month, but does not appear in the subset for last month. So the first thing you'd do is create the two subsets and link them; select once from the table for this month, and select a second time, for last month. Linkthose together and see which students don't appear in both sets. Lookup the LEFT JOIN. also, ear about dates in SQL, your whole concat stuff is very messy and boils down to "AND my1.lesson_booking_date - interval 1 month = my.lesson_booking_date" Never manually transform dates to do comparisons. You pretty much never have to transform dates anyway, but certainly *never* in comparisons because it messes up any optimizations that the database can do to speed things up.