Jump to content

Jacques1

Members
 View Profile  See their activity

  • Posts

    4,207

  • Joined

  • Last visited

  • Days Won

    209

 Content Type 

Everything posted by Jacques1

  1. Jacques1
    You already said that, and I just told you that your approach is stupid. So instead of banging your head against a wall, why don't you choose an approach which actually makes sense? <!DOCTYPE HTML> <html lang="en"> <head> <meta charset="utf-8"> <title>Page title</title> <script src="http://code.jquery.com/jquery-2.2.0.min.js"></script> <script> $(function () { $('.pagelink').click(function () { var targetID = $(this).data('target'); var target = $("#" + targetID); alert(target.text()); }); }); </script> </head> <body> <a href="#" class="pagelink" data-target="row-1">Link to row #1</a> <a href="#" class="pagelink" data-target="row-2">Link to row #2</a> <a href="#" class="pagelink" data-target="row-3">Link to row #3</a> <div id="row-1">This is the content of row #1</div> <div id="row-2">This is the content of row #2</div> <div id="row-3">This is the content of row #3</div> </body> </html>
  2. Jacques1
    The whole approach looks very weird and very inefficient. Why would you use sequential classes? Why not IDs? And what happens when the numbers exceed one digit, thus breaking your substr() hack? You haven't provided any context, but it looks like what you actually want is one sequential ID per row. And the page links should store the corresponding row ID in a data attribute so that you don't have to pull it out of some class name.
  3. Jacques1
    The way you handle your server is suicidal. If you've actually allowed PHP to create arbitrary files/directories within your application folder (as indicated by the mkdir() calls), that means your application may be manipulated at any time. The same permissions you use to create your upload folder may be used by an attacker to, for example, inject malware. You don't want this. The entire application must be read-only for the webserver, and you have to create the folders manually. Using 777 permissions is also insane, even if that was just a desparate attempt of fixing the problem. Permissions must always be minimal. In your case, only the webserver needs execute and write permissions on the upload and tmp directory. So assign the directories to the webserver and then set the permissions to “300”. Read permissions are not required, unless you want the webserver to list the directory content. And other accounts don't need any permissions at all. Last but not least, don't use relative paths, because you never know what they're relative to. If you want to reference a directory next to the current script, use const UPLOAD_DIR = __DIR__.'/uploads'; const TMP_DIR = __DIR__.'/tmp';
  4. Jacques1
    It's a problem with your PHP code, not the NodeJS code. The master key buffer is perfectly fine. This “<Buffer ...>” stuff is just a visual representation. Internally, a NodeJS buffer is a sequence of raw bytes (which also means that you don't need initVector.toString('binary'); just pass initVector straight to the function). In your PHP code, you're still using the hex representation of the ciphertext and master key. You need the raw binary data, so apply hex2bin() to those parameters as well. You also need to set the OPENSSL_RAW_DATA flag. Otherwise, openssl_decrypt() expects a Base64-encoded string, which doesn't make sense in your case. <?php $master_key_hex = "28c03478bbd1874d5c472dd5d6f00ca0"; $cipher = "AES-128-CBC"; $ciphertext_hex = "bf8d6421f518dac424cac43a7a3e25f2"; $init_vector_hex = "a73251f1bcad23e6bf95b1b8ed41dc96"; $plaintext = openssl_decrypt(hex2bin($ciphertext_hex), $cipher, hex2bin($master_key_hex), OPENSSL_RAW_DATA, hex2bin($init_vector_hex)); var_dump($plaintext); I strongly recommend that you append a “_hex” suffix to all hex-encoded strings so that you won't confuse them with the actual binary data. OpenSSL silently truncates overly long keys, but you should still use the correct length.
  5. Jacques1

    Redirect

    Jacques1 replied to RobG's topic in PHP Coding Help

    It's difficult to help when you don't provide any information about your current knowledge and the specific problems you have with the task. What kind of help are you looking for? A basic “Hello World” tutorial which explains how to process form data in PHP? A database tutorial? Something else?
  6. Jacques1
    Ideally, you shouldn't need any handler. Disable both display_errors and display_startup_errors to simulate a production environment. Then create a script with a fatal error and watch the developer tools of your browser. You should see a blank page and a 500 response code. If this works, you have to make Apache intercept this error and display a custom error page. How do Apache and PHP communicate on your production server (not the XAMPP testing stuff)? Via FastCGI? mod_php? CGI? If you don't want to (or cannot) intercept the error with the webserver, you should register a shutdown function as explained in the Dev Shed thread. This function can then render a user-friendly error message.
  7. Jacques1
    So a product belongs to one category (or many categories?), and each category can be further divided into subsections like “casual”? If the “area” is really just an attribute of a product, I'd make three tables: categories, attributes (or areas) and products. Then you assign each product to one category and one attribute. If you need multiple categories or attributes, you need more tables.
  8. Jacques1

    Redirect

    Jacques1 replied to RobG's topic in PHP Coding Help

    What's your current code? What did you try?
  9. Jacques1
    Use a regular expression to simultanously validate the input and extract the postcode area: <?php // test input $postcode = 'S1 4QJ'; $postcode_regex = '/\\A(?P<postcode_area>[A-Z][A-Z]?)\\d[A-Z\\d]? \\d[A-Z]{2}\\z/'; if (preg_match($postcode_regex, $postcode, $postcode_matches)) { var_dump($postcode_matches['postcode_area']); } else { echo 'Incorrect postcode.'; }
  10. Jacques1
    You'll have to be a lot more specific. What exactly do you not understand? The basic structure should be obvious: There are categories, and there are posts. A category has a parent (which may be NULL for root categories), and a post belongs to one (or more?) categories. There's really nothing special. Note that if the number of subcategory levels isn't limited, fetching the category tree with MySQL will be a pain in the ass (since MySQL doesn't support recursive queries). But you can worry about that later.
  11. Jacques1
    You don't need any exception handler. Exceptions are just special fatal errors, and those are either handled by the webserver (which is preferrable) or the shutdown function. Yes. If you're using PHP 5.4 or above (which you definitely should), you can actually pass an anonymous function directly to register_shutdown_function(): <?php register_shutdown_function(function () { // the error handling code etc. }); But like I said, the best solution is to let the webserver handle errors. A shutdown function is only required if you have a bad webserver which cannot do this (Apache?) or very complex error handling code.
  12. Jacques1
    The OOP part is OK (except that you're not passing the PDO instance to the ScriptControl constructor in your example code). The database layout looks odd. What's the type of config_value? Why does the column simultaneously contain integers(?) and time values? Also, you can get the current time in MySQL itself using CURTIME(). There's no need to do that in PHP (unless you somehow want different timezones in MySQL and PHP).
  13. Jacques1
    Both paradigms are easy to understand, both are perfectly valid, and both are widely used in PHP. The advantage of OOP is that it's more powerful than classical procedural code. When your applications grow and become complex, juggling with huge monolithic scripts and unprotected global variables doesn't work very well. You need a more abstract approach to keep the code organized. Namespaces and functions help a bit, but they don't really solve the problem. OOP is perfect for complex applications, because you can hide all the implementation details behind a simple interface and restrict variable access to those parts of the code which actually need it. I think you should learn both paradigms and decide for yourself which one is appropriate for the concrete problem. Procedural programming is conceptually simpler and has less overhead, which is great for small applications. OOP makes sense for mid-sized and large applications. Besides that, it depends a lot on your personal preferences (if you're working alone).
  14. Jacques1
    Instead of tunnelling every single image request through the PHP interpreter (which is inefficient), you can simply tell the webserver to send a particular file. nginx has the X-Accel header for this purpose, Apache has mod_xsendfile.
  15. Jacques1
    No, because then all you get is your old procedural code with a lot of useless OOP overhead. OOP is about objects, not functions. Objects are actors which have attributes and can perform tasks. In your case, an obvious actor would be the current script: It has a path (or some other unique identifier) and a database connection, and it can tell you whether you're allowed to run it. For example: <?php class RestrictedScript { private $path; private $database; public function __construct($path, PDO $database) { $this->path = $path; $this->database = $database; } public function isEnabled() { // query the database } public function isRunnable() { // query the database } } <?php $thisScript = new RestrictedScript(__FILE__, $database); if (!$thisScript->isEnabled()) { echo 'Script is not enabled.'; exit; } if (!$thisScript->isRunnable()) { echo 'Script may not be executed right now. Please try again later.'; exit; } You should, of course, choose a more meaningful name than “RestrictedScript”.
  16. Jacques1
    Then post the updated code.
  17. Jacques1
    You already have a thread for the exact same problem.
  18. Jacques1
    The design of some particular class is irrelevant at this point. You should worry about that later. Like I said, we can't really give concrete advice without concrete information. Generally speaking: If the authorization check is complex, do it in the application, even if that requires an extra query. Don't stuff business logic into queries. The benefit of a transaction is that you don't have to delete any orphaned records at all. Either the entire procedure is successful, or you simply roll back everything.
  19. Jacques1
    The first option seems to be oversimplified. If anything goes wrong while inserting the junction record (which can always happen), you have to go through the exact same steps as in the second option. So really the only difference is whether the authorization rules should be checked in the application or by the database system. I think we need to see them to answer that question. Have you considered using a transaction so that you don't have to clean up your database in case of an error?
  20. Jacques1
    The topic is from October 2015, and the OP hasn't been online ever since (besides, he never seemed to be particularly interested in our advice). I suggest you do close this thread to prevent further abuse. Technical issues can be discussed in Questions, Comments & Suggestions.
  21. Jacques1
    Every operating system supports forward slashes, even odd ones like Windows. Since that's a lot shorter and more readable than DIRECTORY_SEPARATOR, I'd go with forward slashes.
  22. Jacques1
    The PDO code can also be improved a bit: Always set PDO::ATTR_EMULATE_PREPARES to false. Otherwise all prepared statements are silently replaced with a kind of client-side auto-escaping, which is a lot less secure. You should explicitly define the desired character encoding in the DSN string (e. g. charset=utf8mb4). Otherwise MySQL will fall back to a default encoding and may garble non-ASCII characters. Also consider setting the default fetch mode. PDO supports named parameters in prepared statements. Use them! It's a lot more readable than a bunch of question marks. When you connect to 127.0.0.1, you force MySQL to use the TCP protocol. It's generally more efficient to use a UNIX socket by connecting to localhost. <?php const DB_HOST = 'localhost'; const DB_USER = '...'; const DB_PASSWORD = '...'; const DB_NAME = '...'; const DB_CHARSET = 'utf8mb4'; // just an example; choose whatever you need $dSN = 'mysql:host='.DB_HOST.';dbname='.DB_NAME.';charset='.DB_CHARSET; $databaseConnection = new PDO($dSN, DB_USER, DB_PASSWORD, [ PDO::ATTR_EMULATE_PREPARES => false, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, ]);
  23. Jacques1
    So I hurt your feelings back on DevShed? And years later, you still aren't over it? Grow up, kid.
  24. Jacques1
    Hard-coded $_POST references in the application logic are bad, because they tie your entire code to specific details of the HTTP protocol. Actually, it's even worse: You're tied to the low-level superglobals of vanilla PHP. What if you switch to a framework which has a different HTTP interface? What if you want to reuse the code in a different context? You cannot -- unless you manually go through your code and replace the superglobal mess. Stuff like $_POST should only exist in the code which takes care of the HTTP details. Outside of that, you should pass values around and not make any assumptions about their origin.
  25. Jacques1
    What are you trying to achieve? What kind of data are you dealing with, whom do you send it to, and whom are you trying to protect it from? When programmers end up with RSA, they've usually made a couple of very bad design decisions. You should never implement your own public-key systems. Always use established protocols like HTTPS or tools like PGP/GPG.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.