Php login/registration page

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Can anyone explain how i can create a registration and login page using PHP that doesnt use databases, sessions, or cookies?

Is there a tutorial someone can point me to or could anyone tell me the method. Thanks

Re: Php login/registration page

On 9/30/2014 7:04 PM, Apple Sizat wrote:
Quoted text here. Click to load it

You can do it not using a database (i.e. use a flat file).  But if you
don't use cookies and/or sessions, the login will only be active for the
current request.  It will be forgotten as soon as the PHP script ends
(which is before the last data is sent to the client).

Remove the "x" from my email address
Jerry Stuckle

Re: Php login/registration page

On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
Quoted text here. Click to load it

You could add a token to every URL link to leave the page to go to the  
next page, that provides storage for the login information, as long as  
the user navigates via links on your pages.

This could be seen as a version of a "poor mans" session (implementing  
by hand what session code can take care of automatically).

Re: Php login/registration page

On 01/10/14 05:33, Richard Damon wrote:
Quoted text here. Click to load it

And session easy to hijack.



Re: Php login/registration page

On 9/30/2014 11:33 PM, Richard Damon wrote:
Quoted text here. Click to load it

If you aren't storing any information on the server, it has to be more
than a token.  It must contain all of the necessary information - which,
as J.O. indicated, makes it very easy to hijack.

You could also use hidden fields in the page to store information, but
that has the same problem.  Additionally, since the data are coming from
the user, they can't be trusted.

That's the whole reason sessions exist.

Remove the "x" from my email address
Jerry Stuckle

Re: Php login/registration page

On 10/1/14, 8:13 AM, Jerry Stuckle wrote:
Quoted text here. Click to load it

He didn't SAY he couldn't store anything on the server, and it would be  
a bit hard to understand a "registration page" that didn't save  
something somehow on the server. He just said he couldn't (or doesn't  
want to use) databases, sessions, and cookies.

Jerry had already pointed out an alternative to the Database, I was just  
pointing out that it is possible to create something like a cookieless  
session via other means.

Re: Php login/registration page

Quoted text here. Click to load it

Actually you can do it with hidden fields, effectively turning a form
into a giant cookie. What you do is include a cryptographic hash of the
field data whose integrity you want to preserve. To prevent the user
simply rehashing the fields themselves, you include a server-side salt
in the hash. Without access to the PHP source, an attacker would have to
guess not only the salt, but the hashing function and the way the
fields and salt have been combined in order to break it. You can also
customise the session by adding the user's IP address into the
mix, or a timecode if you want the session to expire after a

define('SALT', 'NaCl or something'); // salt for crypto hash
define('TIMEOUT',14400); // max time limit on form
$form.='<input type="hidden" value="'.$name.'" name="name">
<input type="hidden" value="'.$id.'" name="id">
<input type="hidden" value="'.$timestamp.'" name="timestamp">
<input type="hidden" value="'.md5($timestamp.SALT.$name.$id).'"

if (strcmp(md5($_POST['timestamp'].SALT.$_POST['name'].$_POST['id']),
$_POST['check']) == 0) {
        // fields are valid  
        if time() > TIMEOUT + $_POST['timestamp'] {
                // session has expired

In this example we can rely on the timestamp in the form: if the user
had altered it the hashcheck would have failed (in the above version we  
wouldn't know which of the hashed fields has been tampered with if the test  
failed, but that's unlikely to matter, as any tampering should lead to  
rejecting the form.)  

I only use this approach for simple forms - storing a large dataset
would be make for rather bloated forms. It does have the advantage of
not needing any server-side storage of user data though, and the user
doesn't need cookies enabled either.  

Re: Php login/registration page

On 10/2/2014 9:38 PM, GS wrote:
Quoted text here. Click to load it

And like anything else - it is insecure.  Salts are not that hard to
discover, if you have both the source and the encrypted data.  And even
if the salt cannot be determined, the fields in the page can be reused -
i.e. in a cURL request.

I would never recommend someone who uses such insecure techniques.

Remove the "x" from my email address
Jerry Stuckle

Re: Php login/registration page

On Fri, 03 Oct 2014 01:38:44 +0000, GS wrote:

Quoted text here. Click to load it

You only need one [hidden] field to pass as much data as you like, as you  
can put all the data you want to pass in a serialised string form eg json.

However there are flaws:

You're exposing almost all the data to the user, including any hashes  
used to verify the data is unchanged. This may present various attack  

If this is a get request, you'll hit a request string length limit fairly  
quickly. This may limit the usefulness of the method.

To be honest, the exercise as set is an extremely bad one, as it is  
forcing the students to use fundamentally unsafe methods. It would be  
better to teach the building blocks of good secure form handling first,  
and then give them exercises in form handling to complete.

It seems that the lecturer has fallen into the mistake of starting the  
hands on coding before teaching the important fundamentals. A course  
designed around coding websites with PHP should commence with in depth  
explanations and examples of preventing security flaws, validating and  
verifying input, and the mechanisms PHP provides to prevent the users  
messing with the data, rather than exercises that teach coders to hand  
all the data to the user to play with!

Denis McMahon,

Re: Php login/registration page

While everything said so far is true, I think its all a bit
overkill for what was likely intended as a simple exercise in teaching
novice users the very basics of a registration/sign in processes (which
is something a new programmer can relate to and understand a lot more
than security considerations).

I'd think the intention of a non-database registration page would be a
page where the user fills out a form and the data posted writes to a
flat file (which is then subsequently read from for confirming a user is
registered, to access a single member only page).

Something like the following (insecure registration code follows - do
not really use this code):

function register()
  if(empty($_POST['id']) || empty($_POST['pass']))
      throw new Exception('Both id and pass are required fields.');

  $file = '/tmp/user-data';

      file_put_contents($file, '');

  $users = unserialize(file_get_contents($file));

      throw new Exception(
        'That user name is already taken, please choose another!');

  $users[$_POST['id']] = $_POST['pass'];
  file_put_contents($file, serialize($users));

  printf("Thank you for registering %s", $_POST['id']);

$err = '';

    catch(Exception $e)
        $err = $e->getMessage();
<!DOCTYPE html>
    <span style="color:red;"><?php echo $err;?></span>
    <form name='reg' method='post' action=''>
      User: <input type='text' value='' name='id'>
      Pass: <input type='password' value='' name='pass'>
      <input type='submit'>

Matthew Carter (

Re: Php login/registration page

On Fri, 03 Oct 2014 00:24:01 -0400, Matthew Carter wrote:

Quoted text here. Click to load it

But that flat file is a database.

This is one of the issues. You can't store registration information to  
use at a future login time without holding somewhere, on the server, a  
list of users. Regardless of how and where you store it on the server,  
it's a database.

Denis McMahon,

Re: Php login/registration page

Quoted text here. Click to load it

"A database is an organized collection of data." - Wikipedia.

How literal do you take it/where do you draw the line though?  Written
to disk = database?  Stored in RAM = database?  A collection of Pokemon
cards = a database?

In the context of software, I think 99% of the time a reference to a
"database" is a reference to a DBMS, not the literal meaning.

Matthew Carter (

Re: Php login/registration page

Matthew Carter wrote on 10/3/2014 3:16 PM:
Quoted text here. Click to load it

Coherent, terse, functional and likely true.


Ed Mullen
Do Lipton employees take coffee breaks?

Re: Php login/registration page

On 10/3/2014 4:16 PM, Matthew Carter wrote:
Quoted text here. Click to load it

That could be true.  But looking at the requirements again, it doesn't
seem ANYTHING needs to be saved.  Please point to a single requirement
which stats that.

OTOH,  the requirements indicate data is only to be passed via hidden
fields - which would indicate nothing saved.

Remove the "x" from my email address
Jerry Stuckle

Re: Php login/registration page

Quoted text here. Click to load it

Well, since you have to store the login information somewhere, you can't  
given your restrictions.  Truly, it has to go either in a database, in a  
session variable, or be stored on the brower as a cookie.

So the answer is No, someone can't explain how to do this.

DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]

Re: Php login/registration page

Quoted text here. Click to load it

One possible way would be to dispense with PHP and computers and
the Internet entirely, and hire grad students.

Quoted text here. Click to load it

You need to store information about registered users *somewhere*.
A database provides protection against data getting clobbered when,
say, two new users sign up at the exact same time.  You could use
a flat file for this, with sufficient locking against simultaneous
updates of a flat file.  If you don't understand why this is
necessary, or how to do it, you're going to get it wrong.  It might
be wrong too if your OS gets it wrong.  Since you asked the question
above, you're probably going to get it wrong if you try to do it
yourself.  No, that's not intended as an insult.  Even the pros get
it wrong sometimes.

Where do you intend to keep the information on registered users?

Unless you intend to have the session end when you click on the
login page, or requiring entering login information on *EVERY* page,
you need to be able to track which page goes with which session
somehow.  Otherwise, two sessions logged in as the same user will
interfere with each other.  PHP provides a way to do sessions without
cookies (a variable is added to each URL - see the PHP configuration
variable session.use_trans_sid) - but that's still sessions.  This
tends to be a security hole.  It appears in the browser address
bar.  A user cutting and pasting a URL and posting it or sending
it to someone may give away access to their account, or cause two
users with the same session ID to interfere with each other in odd
ways (such as, for example, paying for someone else's airline
ticket with your credit card).

You could use Apache's "plain" authentication.  This involves: (a)
the browser will pop up a request for a username and password when
you navigate to a protected page, and you have no control whatever
over what it looks like, (b) the browser caches this information
so the user doesn't have to enter it on every page, and (c) there
is NO "logout" function.  This option is so popular I've never seen
it used on any web site actually intended for viewing by the public
(as opposed to a test site used for learning.)  This doesn't solve the
problem that two users logged in with the same user name interfere
with each other.  ISPs often provide this method (it comes free with
Apache), but users are normally responsible for their own web design or
have to hire someone to do it for them.

Site Timeline