Jump to content

benanamen

Members
  • Posts

    2,134
  • Joined

  • Last visited

  • Days Won

    42

Posts posted by benanamen

  1. You need to use prepared statements. You never ever send user supplied data directly to the database. Your code is just waiting for an SQL Injection Attack. Get rid of all those variables for nothing.  Turn on error reporting and check your logs.

     

    I suggest you use PDO instead of Mysqli

    https://phpdelusions.net/pdo

     

    * Good job on using if( $_SERVER['REQUEST_METHOD'] == 'POST')

  2. So in your example, if the value is null, you're just hiding an error with @? Also, there is a pretty significant difference from what I posted and your example, one is dynamic, the other is not.

     

    Good point on the empty(). Sure enough, a field with zero will be skipped. I always want to know everything wrong with a piece of code.

     

    I probably would never even use the posted code but it would seem that you would not want to skip empty strings on an update. How else are you going to update a column with data to no data?

     

    I will have to spend some time with the is_array flag. I still don't understand it.

  3. You have the order of the query wrong. UPDATE SET WHERE



    UPDATE table_name
    SET column1=value, column2=value2,...
    WHERE some_column=some_value 


    By the way, $_SERVER['php_self'] is vulnerable to an XSS Attack.

     

    You need to use prepared statements as well. You NEVER EVER send user supplied data directly to the database.

     

    Don't SELECT *. Specify the column names you want.

     

    You don't have to manually close the DB connection. Php does it automatically when the script is done running.

     

    This doesn't make sense. If NOT submitted? Your logic is flawed.



    if(!$_POST['submit']){

  4. @requinix, The first part of the question was in reference to the code in the linked article regarding injection. I wanted to know if there was something I wasn't seeing in regards to injection in the similar code I posted. I know prepared statements are better and the posted code does generate a prepared statement.

     

    The second part was, if you are going to dynamically generate a query, is there a better way to dynamically generate it than the posted code.

     

    @Jaques1, I figured a dynamic query would go in a function. It would be pointless to keep writing the same thing more than once. I looked up the strict flag and even tested it here http://in_array.onlinephpfunctions.com/. I can't tell what the flag is doing or not doing. 

     

    I have never seen the example you posted. What can you tell me about it?

  5. I saw this code on another forum and tried to reconcile it to the SQL Injection article here: https://phpdelusions.net/pdo/sql_injection_example

     

    My question is, is this version I found safe? Is there a better way to do the same thing?

    <form method=POST>
    <input type=hidden name="data" value="sumdata">
    <input type=hidden name="title" value="sumtitle">
    <input type=hidden name="id" value="1">
    <input type=submit>
    </form>
    
    <?php
    
    if ($_SERVER['REQUEST_METHOD'] == 'POST')
        {
        $columns = ['title', 'data', ];
        $where = [];
        $values = [];
    
        foreach($_POST as $key => $val)
            {
            if (empty($val) || !in_array($key, $columns))
                {
                unset($_POST[$key]);
                }
              else
                {
                $where[] = " $key = ? ";
                $values[] = $val;
                $id = $_POST['id'];
                }
            }
    
        if (!empty($where))
            {
            array_push($values, $id);
            $where = implode(', ', $where);
            $sql = "UPDATE table SET $where WHERE userID = ?";
    
            // $stmt = $pdo->prepare($sql);
            // $stmt->execute($values);
            // These prints are JUST for showing you what happens in the query
    
            echo $sql;
            echo "<pre>";
            print_r($values);
            echo "</pre>";
            }
          else
            {
            echo "Update was not Successful.";
            }
        }
    ?>
    
  6. No. When the code is syntactically invalid, it doesn't get executed at all, so any runtime error settings have no effect.

     

    Besides that, it makes a lot more sense to set up a proper development environment with the right PHP settings rather than messing with the configuration on a per-script basis.

     

    After testing, I see that is correct.

     

    I thought ini_set in the file overrode everything but it doesn't on syntax errors. Always a good day when I learn something new. Thank you gentlemen.

  7. putting the error settings in your file won't help with php syntax errors in the same file because the code never runs to cause the settings to take effect. you need to put these settings into the php.ini

     

    Somebody correct me if I am wrong, but I believe turning on error reporting and setting display_errors at the top of a script is the exact same thing as setting it in the .ini except for it being a global setting.

  8. You have several undefined index errors. If you turn on error reporting you would know exactly what is wrong. When I fixed those, it works fine with stop id 11

    <?php
    
        $_GET['stopid'] = 11; // Benanamen Mod
    
        $url = "https://data.dublinked.ie/cgi-bin/rtpi/realtimebusinformation?stopid=" . $_GET['stopid'] . "&format=json";
    
        // Process the JSON and check for errors
        $json = file_get_contents($url);
        $array = json_decode($json,true);
    
    echo "<pre>";
    print_r($array);
    echo "</pre>";
    die;
    
  9. It should make no difference at all developing on localhost. Even with a domain and hosting account, you would still not be developing on a remote server, although you could.

     

    A couple of the name places to buy a domain is godaddy.com and register.com. As far as hosts, there are thousands to choose from. You also need to decide if you want shared hosting, VPS, dedicated server, managed, self managed. Best to do some research. But really, there is no reason to do all that if you are not ready to go live with a site.

  10. When asking for help on a forum, there are certain questions we expect to be answered to help you. Saying you need help doesn't help us to help you.

     

    1. What have you tried - You posted your code, that's good

    2. What was the result?

    3. What is the expected result - In this case it is obvious

     

    Is error reporting turned on? Have you checked the error logs?

     

    Put this at the top of your script. Now what happens?

    error_reporting(-1);
    ini_set('display_errors', '1');
    
  11. i think thats right anyway,

     

    Well, that's not what I was getting at. The error check should come first, not last. Logically, a login error will always happen before a valid login, and a valid login will not happen before a login error.

  12. Of course it's blank. All your doing is setting $error. The script is done by the time you get to this point. Think this through, I am sure you can figure out what needs to be changed.

     

     

            } else {
                $_SESSION['loggedIn'] = false;
                $error = "Invalid username and password!";
            }

     

     

    FYI: This is no kind of logging in code you should be using.

  13. OP, an aside from whatever you're trying to do here, you can avoid clustmuck arrays by using the range function. I have already fried my brain on another problem to even begin deciphering what your doing although you have confirmed my keen spidey sense of an XY Problem. I couldn't tell you why at the moment, but whatever you're doing, you're doing it wrong. I am sure someone will get you proper answers before I can get back to you again.

    <?php
    $days = range(1,25);
    print_r ($days);
    ?>
    
×
×
  • 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.