Jump to content

Jacques1

Members
  • Posts

    4,207
  • Joined

  • Last visited

  • Days Won

    209

Community Answers

  1. Jacques1's post in Is there a way to get user's timezone using PHP? was marked as the answer   
    No, there is no way to get the client's timezone with PHP. As you probably know, PHP runs on the server, and the HTTP requests sent by the clients don't contain any timezone information.
     
    What you can do is try to get the timezone with JavaScript or make the user explicitly select their timezone. You can also use the IP address and a geolocation database to make an educated guess (but you still need a way for the user to correct the information).
  2. Jacques1's post in How to split a search strings and put it into a prepare statement? was marked as the answer   
    There is nothing to be shown. You create as many parameters as you need, you pass the array to execute(), and that's it.
    $searchTerms = explode(' ', $_POST['strings']); $searchStmt = $databaseConnection->prepare(' SELECT * -- list the specific columns! FROM core_table WHERE item_name IN (NULL '.str_repeat(', ?', count($searchTerms)).') '); $searchStmt->execute($searchTerms);
  3. Jacques1's post in store echo value on a variable was marked as the answer   
    Do you not understand that there's a difference between the number 80 and the string “$80”? Can't you see the dollar sign? This will fudge up any calculations, because PHP cannot convert that into a meaningful number (so it converts it to 0).
     
    You need to repair your database. The price must be stored in a numeric column (e. g. DECIMAL) without any currency symbols. If the currency is always the same, you don't need to store it at all. If there are different currencies, I recommend you store them in an additional column and then add the currency symbol in the application.
  4. Jacques1's post in Login with password_verify() fail all time was marked as the answer   
    First off, you need to get rid of this strip_tags() nonsense. This can in fact destroy your passwords, because it blindly removes anything that looks like HTML markup.
     
    The password_verify() function works like this:
    if (password_verify($the_password_to_be_checked, $the_stored_password_hash)) { // correct password } else { // wrong password }
  5. Jacques1's post in Automatically Include files based on name in a directory was marked as the answer   
    Like I said above: Use a standard format like JSON or XML. PHP already has parsers for those.
     
    For example:
     
    config.json
    { "name": "some_name", "description": "some description", "version": "1.0", "author": "RMorrison" } Parsing:
    <?php $config_content = file_get_contents('/path/to/config.json'); $config = json_decode($config_content, true); // echo the version number for testing echo $config['version'];
  6. Jacques1's post in What is the proper way to return an array from a prepare statement function? was marked as the answer   
    The proper way is to replace mysqli with PDO. If that's not an option, get_result() is OK as a workaround. It does require the MySQL native driver, though (which isn't available on all systems).
     
     
    It's theoretically possible with call_user_func_array() and an array of references, but this is really ugly.
  7. Jacques1's post in PHP Fatal error: Call to a member function prepare() on null was marked as the answer   
    A prepared statement doesn't have a fetch_array() method. Read the manual on how prepared statements work.
     
    Actually, you don't need this at all, because you have no external input. The entire method can be boiled down to
    function listMerchant() { return $this->mysqli->query('SELECT col1, col2, ... FROM core_merchant')->fetch_all(MYSQLI_BOTH); }
  8. Jacques1's post in If I may be permitted - Permissions ! was marked as the answer   
    First, every directory and file of the application should be owned by an administrative user (like the one you use to SSH into the machine), not the webserver. The group should be the group of the webserver (usually www or www-data).
     
    Appropriate permissions for read-only directories are: read+write+execute for the user, execute for group, none for the world. This means the administrative user can do anything, the group (i. e. the webserver) can only enter the directory, everybody else has no permissions at all.
     
    For writable directories: read+write+execute for the user, write+execute (and possible read) for the group, none for the world.
     
    The minimal permission required to use a directory is “execute”. “Read” means that the files in the directory can be listed (which is usually not necessary and may be dangerous). And “write” allows creation of new files.
  9. Jacques1's post in Using PDO format in php was marked as the answer   
    The whole approach of building the table with dynamic query gymnastics is bad, so you shouldn't try to replicate this with PDO at all.
     
    I know this is hard to understand, but SQL is not Excel. SQL is supposed to store and provide data, not render pretty tables. That's what your application is for.
     
    So use your database to retrieve the data (i. e. the sum per date and type), and then write code to produce your pivot layout. So the query is simply
    SELECT datetransact, transactiontype, SUM(transactioncount) AS transactions FROM dummy_transaction GROUP BY datetransact, transactiontype ;
  10. Jacques1's post in suggestions on cleaning up my coding was marked as the answer   
    Trying to remove security vulnerabilities afterwards is a bad strategy which almost never works. Sooner or later, you're going to overlook a vulnerability or simply give up this tedious task. Instead, use secure programming techniques from the beginning. Don't ever let unsafe values near your SQL queries or HTML markup, not even for a quick prototype.
     
    As to the HTML, I strongly recommend you use a template engine like Twig. While it's theoretically possible to generate HTML with plain PHP like people did in the 90s, this almost always ends up in an ugly mess of spaghetti code and XSS vulnerabilities. Twig prevents this by strictly separating the code from the markup, by auto-escaping all input and by providing a much nicer syntax.
     
    Stuffing all your functions into one giant functions.php script is also a bad idea, because nobody wants to read through that. Instead, modularize your application. Put related functions into separate scripts.
     
    The session and security stuff is copied and pasted from wikiHow, right? Don't do that. A lot of people publishing code on random websites know less about PHP than you do. Copypasta also means the code will never receive any updates and just keep rotting in your application. If you want to use existing tools, pick a trustworthy source (active GitHub projects with multiple contributors are good candidates) and use a mechanism which supports updates (e. g. Composer).
     
    In your case, you can simply remove the wikiHow stuff and use the Password Hash API instead.
  11. Jacques1's post in How do you debug imagerotate()? was marked as the answer   
    I would consider using a vector graphic (i. e. SVG) where you can actually rotate the needle with a parameter. This will be a lot less painful than raster image manipulation.
  12. Jacques1's post in leaving out null rows was marked as the answer   
    A human-readable version of your query:
    SELECT player_details.player_id AS P_id, CONCAT(player_details.Fname, ' ', player_details.Lname) AS pname, positions.position_id, positions.position FROM Soka_player_details_tbl AS player_details JOIN Soka_players_team_tbl AS team_players ON team_players.player_id = player_details.player_id JOIN tbl_season AS seasons ON seasons.SeasonID = team_players.SeasonID JOIN Soka_position_tbl AS positions ON positions.position_id = team_players.position_id WHERE seasons.Publish AND team_players.Team_catId = '1' ORDER BY team_players.position_id ASC ; (untested)
     
    Your table and column names definitely need to be improved (rAnDOM ChAnGES oF CHarActER caSE and random tbl_ prefixes and suffixes aren't very helpful). I've used aliases for now.
  13. Jacques1's post in unable to verify old password was marked as the answer   
    In your form, there must be a field for the old password. Let's call it “oldpassword”. This is what you need to verify:
    if (!password_verify($_POST['oldpassword'], $row['password'])) { // wrong password } ...
  14. Jacques1's post in include - a mystery to me was marked as the answer   
    The problem with relative paths is that it depends on the environment what the paths are relative to. The current directory could be anything.
     
    So do use absolute paths. You can still start with the current script by using the __DIR__ constant:
    require_once __DIR__.'/../oldstuff.php'; Another option is to define your own constant for the base directory of the application and start from there:
    <?php define('APPLICATION_DIR', $_SERVER['DOCUMENT_ROOT'].'/mninfo'); <?php require_once APPLICATION_DIR.'/oldstuff.php'; Then you don't have to jump around with “..”.
  15. Jacques1's post in Modal Box Pop Up, Setting cookie with timer was marked as the answer   
    You cannot set cookies after you've generated HTML markup. Cookies are set in the HTTP header, but the markup is in the HTTP body which comes after the header. Once you start sending body data to the client, it's too late to do anything with the header. PHP cannot travel back in time (it can theoretically buffer the message, but this is complex and not recommended in your case).
     
    So you have to set the cookie before you generate any page content. There must be no output before the setcookie() call. No <html>, no <head>, not even whitespace. Nothing.
     
    As I already said, you need to fix your spaghetti code. I -- again -- strongly recommend you set the cookie with JavaScript. Not with PHP. With JavaScript. If, for some strange reason, that's not an option for you, you'll have to reorganize your PHP script to look something like this:
    <?php // this is the first line of the script; there must be nothing before this if (isset($_COOKIE['modal_seen'])) { $show_modal = false; } else { $show_modal = true; setcookie("modal_seen", "true", time() + 3660, "/"); } // now the HTML markup ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Title</title> </head> <body> <!-- ... --> <?php if ($show_modal): ?> <script type="text/javascript"> $(window).load(function(){ $('#modal-box').modal('show'); }); </script> <?php endif; ?> <!-- ... --> </body> </html> I strongly recommend against this. It's just bad programming.
  16. Jacques1's post in Select query not working when defining ID was marked as the answer   
    Then use the ID from the URL. Not from the database. The URL. As in:
    $id = mysqli->real_escape_string($_GET['tour_id']);
  17. Jacques1's post in PDO safe inserting data into database was marked as the answer   
    I think I've already told you this several times: You do not apply HTML-escaping or any other manipulation before you insert the data. This effectively damages the input and makes it unusable. For example, the username “I <3 PHP” would become “I <3 PHP”. Good luck doing a text search on that.
     
    Escaping is done when you output data, and it must match the specific context. HTML-escaping only works for HTML contexts, shell-escaping only works for shell contexts etc.
     
    The functions you've found in that CMS are braindead. You should generally stop using random code from the Internet. Think for yourself.
  18. Jacques1's post in creating a search form was marked as the answer   
    Yes, but you also need to understand what to replace the percent character with. Right now, you're replacing it with an underscore which stands for “exactly one arbitrary character”. Obviously that doesn't help.
     
    If you want percent characters to be interpreted literally, you need to escape them with backslashes:
    $search = '%'.str_replace('%', '\\%', $_GET['text']).'%';
  19. Jacques1's post in [PHP] image upload script don't works was marked as the answer   
    $_FILES
  20. Jacques1's post in inser_id() { not inserting for me says wrong integer was marked as the answer   
    You should construct dynamic queries with prepared statements. Not only does this solve a lot of security vulnerabilities. It would also fix your current problem without any extra checks, because if $attributes['id'] is null, a prepared statement maps that to an SQL NULL, which is a perfectly valid value for an auto-incremented integer column.
     
    Your code, on the other hand, wraps all values in quotes, so you end up trying to insert an empty string into an integer column.
  21. Jacques1's post in The right needle in a haystack ! was marked as the answer   
    Just to make sure we agree on the terminology and concepts (because some parts of the original post sound strange to me).
     
    With “production server” I mean the public webserver which you have rented (or will rent) to host your website on the Internet. You would never install XAMPP on a production server, because a) XAMPP is meant for developer PCs, and b) it's just not necessary. When you rent a webserver, it usually has Apache, PHP, MySQL etc. already preinstalled, or you can easily install this software with a package manager.
     
    The OS on a public webserver must obviously be stable and secure, so common choices are Debian, CentOS, OpenBSD, ...
     
    When I suggested a VM, I meant a local test environment to replace your current XAMPP setup. A test environment should match the public webserver as closely as possible. So if your public server uses Debian, Apache, MySQL etc., then you would install Debian, Apache, MySQL etc. in the VM.
     
    The VM doesn't need a desktop GUI, because you just use it to run your application. The actual programming still happens on your Windows PC (or whatever it is you're using). If you want a Linux desktop for programming, that's another story.
  22. Jacques1's post in PHP and Token Authentication was marked as the answer   
    Both thephpleague/oauth2-server and bshaffer/oauth2-server-php are very active, have been around for a while and are in fact mentioned on the “official” site (if that helps).
     
    But even if the project dies in a couple of years – so what? Switching to a different library is still much, much less work than writing your own from scratch and maintaining it (just look at the number of contributors and commits). You could even implement an abstraction layer (e. g. a couple of wrapper functions), so that the application doesn't rely on any library-specific features.
  23. Jacques1's post in Using float values in JSON was marked as the answer   
    The client essentially subverts the type flexibility of InfluxDB by appending an explicit “i” whenever it encounters a PHP integer.
     
    If there's no better client, cast the arguments of the Point constructor:
    $point = new Point($measurement, (float) $value); Or change the source code.
  24. Jacques1's post in I have an array that I need to get into a db was marked as the answer   
    You don't need no regular expressions. Just look at the output of the command in the console and then split the string at the right characters. Surely you can recognize a newline and a tab.
     
    In my case, that's
    foreach (explode("\n", $arpOutput) as $host) { list($ip, $mac) = explode("\t", $host); echo "IP address: $ip, MAC address: $mac<br>"; }
  25. Jacques1's post in Regarding .htaccess was marked as the answer   
    To make it short: Virtual paths like /items/p/ and relative physical paths like search.php don't go well together. The browser will end up trying to access nonsense URLs like /items/p/search.php, because it assumes it's actually within the directory /items/p/.
     
    Use absolute paths instead. For example, if your PHP script is directly below the document root, that's
    /search.php In the long run, you should also consider switching to virtual (“pretty”) URLs altogether. Then you can completely decouple the physical script paths from the URLs.
×
×
  • 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.