How to deal with updating database on every user interaction

[Pelle_3]

I am quite new to web development, so I naturally came to a point where I needed some help. I am making a web site where the user has to log in, and if authentication is successful, the user's data will be fetched from server and displayed on page (and can be edited by user). Because the web site is highly dynamic, the user will click around a lot and change this data, so changes has to be continously uploaded to the server.

I have the index.html where a pop-up box (modal. I'm using Bootstrap) opens for user to enter username and password. That's handed to server with a post command over https (http while developing). a PHP file looks up in the mySQL database and checks if info is corrrect (log in credentials are stored hashed with salt. I'm checking for sql injections also) If it's correct, it echoes "1" back, or "0" if incorrect. The client now knows it’s logged in. But what do I do when the user changes things and new data has to be uploaded to the server? Do I have to pass the username and password to the server again, and to the whole authentican process over again? This may happen more than 30 times a minute.

A have a few other questions as well, but I’ll start with this. I have spent many hours trying to find the answers myself, but I'm really lost in what's the best way of going about this.

[diafol]

You store the user's id in a session variable. So every single page needs to have a

session_start();

Immediately after the first opening <?php tag. Technically it doesn't have to be the first line, but it can solve a lot of problems later on if it is.
Placing this in every single page is a pain, so usually we place it in an include file, such as a configuration file. The way you handle this is all down to how you build your pages.

So for example, in each 'container' page, you'd have something like this:

<?php
require '../includes/config.php';
...

ANyhow, once you have sessions set up, you can store your user's id in a session variable so that you no longer have to worry about who this person is.

Here's a typical login script (using PDO)...

if(isset($_POST['username']) && isset($_POST['password']))
{
    //VALIDATE these POST vars before proceeding...

    $username = $_POST['username'];
    $pw = $_POST['password'];
    $sql = 'SELECT `id`, `password`, `userlevel` FROM users WHERE username = ? LIMIT 1';
    $stmt = $db->prepare($sql);
    $stmt->execute(array($username));
    if($data = $stmt->fetch(PDO::FETCH_ASSOC))
    {
        if(password_verify($pw, $data['password'])) 
        {
            $_SESSION['user_id'] = $data['id'];
            $_SESSION['userlevel'] = $data['userlevel']; //optional
            $_SESSION['username'] = $data['username']; //optional
        }else{
            //login failed pw doesn't match
        }


    }else{
        //login failed username does not exist
    }
}

Now you have the user's id in every page they visit until they log out. So you can use this to log all changes without having to ask the user to authenticate every time.

[Pelle_3]

Thank you for the thorough answer. I have read a lot about sessions, but didn't think it was applicable here because there will only be one html page. I guess that doesn't really matter. Is it so that only the client that sent a request to create the session will have the priveliege to access the session id (if that makes sense)? I know I have to put in code to stop session hijacking and so on as well. If two different users logged in, they would be assigned different session id's, but neither one have to send any authentican data to the server again for as long as the sessions exist?

[diafol]

A session is created automatically before the authentication form is sent. Sessions are known as server-side cookies. When the session id on the client matches the session id kept on the the server, we are then able to read and write session vars to that session. The session id is not the same as the session user_id. A session id should be unique to an user. It should be unique to a user in a specific browser. SO an user logging in on CHrome and the same user loggin in on IE on the same machine will have different session ids.

Once a session has a user_id associated with it, you can treat that as that user being 'logged in'. Unless the user shares this session id with somebody (wittingly or unwittingly), it is very difficult to get the user's session id, and therefore access to the session data and ability to change site data as the user. SO it's reasonably safe. However, do read up on session hijacking and fixation.

NEVER store a password in a session, and if a an user needs to perform an higher level task, like change a pw, ensure that they have to authenticate again. That prevents malicious users from messing with user access if the original user has left his/her desk but still logged in.

Mind you, anybody daft enough to do that, deserves everything they get, but if they're a site moderator or admin, that could have a devastating effect for you. There's no real defence against that though.

[Pelle_3]

Thank you! I feel I understand this pretty well now. I'll read some more about session hijacking and fixation to make things as secure as possible.