[AVReidy]

I'm fine with cookies and session variables, but I'm not sure how to go about securely storing the state of a user, be it logged in or logged out.

First of all, should I store <whatever I should be storing> in cookies or session variables? Is it possible for a user to view or modify session variables like they can cookies? Also, what exactly should I be storing in order to check which user is logged in? I would want to say it would be convenient to store the user's ID (or increment in the database), but if I stored this in a cookie it would not be difficult for a malicious user to go in and say, "Hmm, who's account do we feel like messing around on today? ID 3? *Changes cookie to 3* Sweet!" So, what are cookies good for other than storing (possibly) long-term and non-sensitive preferences?

By that I mean: people don't use cookies for storing log-in stuff, do they? Wait, this site is probably doing that for me right now since I told it to stay signed in... what the heck...)

Thanks for your help!

This post has been edited by AVReidy: 31 January 2012 - 04:27 PM

[Dormilich]

usually you store the logged-in status in a session, since the user cannot modify that (it’s on the server).

for the stay logged-in stuff you usually use 2 (or more) data in a cookie that have to match up to start a logged-in session (just like used-ID and password).

[AVReidy]

When a website offers to keep a user logged in for an extended period of time by using cookies, do they encrypt the two credentials that should match up? And are they different every time? Storing stuff like that in cookies seems like it requires some sort of random encryption because if it doesn't, that means I could inject some Javascript, copy the cookies, and paste them without ever having to log in.

[Dormilich]

I don’t think they are different each time. I mean, you only need to check whether your DIC cookie settings differ somewhere.

This post has been edited by Dormilich: 31 January 2012 - 05:28 PM

[codeprada]

They must be different every time or else it will become a security issue. You don't want someone having permanent access to an account if they somehow get the cookie associated with the remember me feature.

Don't use Javascript for any type of authentication. It's client side thus editable.

A short rundown of what happens in a remember me (from my perspective)...
When the user logs 2 random strings are generated. One stored in a cookie on the client and the other in a database on the server. These two strings are however hashed to create the final string that will be used for identification. The final string too is stored in the database but it is associated with an user account.
When the user visits the site and is not logged on you will try and retrieve the string from both the client (cookie) and the database. Run the same hash function on them and then query the database for a matching account.

Note that this does not authenticate a user but simply identifies them.

This post has been edited by codeprada: 31 January 2012 - 05:33 PM

[AVReidy]

So if I use sessions to create a simple log-in system, would it be okay to store the user's ID (perhaps an auto-incremented "user_id" in the database) as a session variable? I think this would be sufficient for getting everything a webpage would need for an authenticated user, but storing something as simple as "13" as everything keeping a user logged in seems a little shaky. I have briefly looked over the log-in system in a book I have, and it uses some stuff that I'm not familiar with - that's why I'm asking around here to get the big picture of how this stuff works.

[codeprada]

Using just the user_id wouldn't be as secure as a log-in system should be. It will work yes but at what cost. Have a look at a tutorial I wrote a while back on authentication users.
User Authentication via Two Keys & IP Address

There's also a class which applies the same principle explained in the tutorial.
UserAuthentication Singleton

This post has been edited by codeprada: 31 January 2012 - 08:04 PM

[AVReidy]

So session variables are not secure? I don't see why using only the user_id would be insufficient if they are secure.

[Dormilich]

AVReidy, on 01 February 2012 - 10:28 PM, said:

So session variables are not secure?

I don’t think that is what codeprada meant. session variables themselves are among the most secure (persistent) things in a web application you can have. (but that doesn’t mean that you can’t attack a session)

[AVReidy]

This is slightly on a different note, but not worthy of starting a new thread:

I'm wondering if there's an easy way to check if a user has already been created in a database (to prevent multiple accounts with the same name). I don't want to run a loop every time someone tries to create an account to check if the name is in use...

Thanks.

[Atli]

It shouldn't be necessary, unless you want to set up some sort of a real-time name check thing with AJAX.

Any field within a database that should be unique (like a username and email) should be a Unique Key. The database would them simply refuse to re-register taken usernames and emails.

In MySQL, this is done by adding the UNIQUE keyword to the definition of a column.

CREATE TABLE `member`(
    `id` SERIAL PRIMARY KEY,
    `name` VARCHAR(65) NOT NULL UNIQUE,
    `email VARCHAR(255) NOT NULL UNIQUE
)

Any INSERT done on this table where the email or name columns already have the value you are trying to insert will fail with an error. You can catch that in your PHP script and show it to your users.

[AVReidy]

Thanks Atli.

I got started on a site with a log-in system tonight, and I'm getting along pretty well. Except for when I decided to make a PHP class that uses (dare I say it) variables outside of functions. I'm getting tons of "Unexpected T_VARIABLE" errors in this code. I'm new to OO PHP, but I can already tell this feature just doesn't work well in PHP. Or I don't have a clue what I'm doing. Or both.

Here's my code, I'd really appreciate it if you could tell me what I'm doing wrong because I'd like to use an OOP approach even if it means using the nice, implicit "this->" everywhere.

<?php

require 'Scripts\db_connect.php';
require 'Scripts\Validate.php';
	
class Creator {

	public $ret = false;
	
	public $raw_un = $_REQUEST['username'];
	public $raw_pw = $_REQUEST['password'];
	public $cleaner = new Validate();
	public $username = $cleaner->clean_string($raw_un);
	public $password = $cleaner->clean_string($raw_pw);
	public $un_length = strlen(this->$username);
	public $pw_length = strlen(this->$password);

	function create() { //Checks if valid, then inserts into database, creating a new user.
		if (this->$un_length <= 30 && this->$un_length > 0 && this->$pw_length <= 30 && this->$pw_length > 0) {
		mysql_query("INSERT INTO users (username, password) VALUES ('{this->$username}', '{this->$password}');");
		this->$ret = true;
		}
	return this->$ret;
	}
}

?>

At the moment it's just giving me errors on the $_REQUEST lines.

This post has been edited by AVReidy: 01 February 2012 - 07:23 PM

[Dormilich]

straight from the manual:

Quote

Properties

Class member variables are called "properties". You may also see them referred to using other terms such as "attributes" or "fields", but for the purposes of this reference we will use "properties". They are defined by using one of the keywords public, protected, or private, followed by a normal variable declaration. This declaration may include an initialization, but this initialization must be a constant value--that is, it must be able to be evaluated at compile time and must not depend on run-time information in order to be evaluated.

the initializations you do are on runtime, hence the error(s).

check also the examples for what is valid.

This post has been edited by Dormilich: 01 February 2012 - 07:47 PM

[Atli]

There are two things there that I would point out.

First, the proper use of the this keyword is like: $this->something, not this->$something.

Second, you'll want to initialize any non-constant value inside a constructor rather than in the class body. There are much stricter rules regarding what you can and can not initialize class attributes to in the class body. This is because the class is not actually an object, but a "blueprint" for an object.

In short, if you are planing to do something like this:

class foo
{
    public $word1 = "Hello";
    public $word2 = "OOP";
    public $created_at = time();
    public $sentence = $this->word1 . " " . $this->word2;
    
    public function speak()
    {
        echo $this->sentence;
    }
}

Only the "word1" and "word2" values are valid. The others are not constant, but rely on function return values or instance values. (Remember, a class is not an instance, so $this has no meaning in the class body, only inside class methods.)

What you would want to do instead is this:

class foo
{
    public $word1;
    public $word2;
    public $created_at;
    public $sentence;
    
    public function __construct()
    {
        $this->word1 = "Hello";
        $this->word2 = "OOP";
        $this->created_at = time();
        $this->sentece = $this->word1 . " " . $this->word2;
    }
    
    public function speak()
    {
        echo $this->sentece;
    }
}

The __construct method is a special type of method that is executed once when every instance is created, to initialize the instance. - Like I mentioned before, you can set constant values for attributes in the body, so the "word1" and "word2" values could be set the way they are in the first example, but in general it's best to just keep all initialization inside a constructor.

[AVReidy]

Thanks again Atli, that helped a lot.