Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14255 > unrolled thread

Php login/registration page

Back to article view | Back to comp.lang.php

Contents

  Php login/registration page Apple Sizat <afor6993@gmail.com> - 2014-09-30 16:04 -0700
    Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-30 20:55 -0400
      Re: Php login/registration page Richard Damon <Richard@Damon-Family.org> - 2014-09-30 23:33 -0400
        Re: Php login/registration page "J.O. Aho" <user@example.net> - 2014-10-01 06:51 +0200
        Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-01 08:13 -0400
          Re: Php login/registration page Richard Damon <Richard@Damon-Family.org> - 2014-10-01 22:37 -0400
          Re: Php login/registration page GS <nomail@nospam.org.invalid> - 2014-10-03 01:38 +0000
            Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-02 21:43 -0400
            Re: Php login/registration page Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-03 03:29 +0000
              Re: Php login/registration page Matthew Carter <m@ahungry.com> - 2014-10-03 00:24 -0400
                Re: Php login/registration page Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-03 18:33 +0000
                  Re: Php login/registration page Matthew Carter <m@ahungry.com> - 2014-10-03 16:16 -0400
                    Re: Php login/registration page Ed Mullen <ejEVOMER@edmullen.net> - 2014-10-03 18:24 -0500
                    Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-03 20:37 -0400
    Re: Php login/registration page Michael Vilain <vilain@NOspamcop.net> - 2014-09-30 18:38 -0700
    Re: Php login/registration page gordonb.opkrz@burditt.org (Gordon Burditt) - 2014-09-30 21:08 -0500

#14255 — Php login/registration page

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

[toc] | [next] | [standalone]

#14256

On 9/30/2014 7:04 PM, Apple Sizat wrote:
> 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
> 

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
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14259

On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>> 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
>>
>
> 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).
>

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).

[toc] | [prev] | [next] | [standalone]

#14260

On 01/10/14 05:33, Richard Damon wrote:
> On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
>> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>>> 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
>>>
>>
>> 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).
>>
>
> 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).

And session easy to hijack.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14261

On 9/30/2014 11:33 PM, Richard Damon wrote:
> On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
>> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>>> 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
>>>
>>
>> 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).
>>
> 
> 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).

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
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14263

On 10/1/14, 8:13 AM, Jerry Stuckle wrote:
> On 9/30/2014 11:33 PM, Richard Damon wrote:
>> On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
>>> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>>>> 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
>>>>
>>>
>>> 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).
>>>
>>
>> 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).
>
> 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.
>

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.

[toc] | [prev] | [next] | [standalone]

#14276

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 9/30/2014 11:33 PM, Richard Damon wrote:
>> On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
>>> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>>>> 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
>>>>
>>>
>>> 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).
>>>
>> 
>> 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). 
> 
> 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.
> 

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
while. 

define('SALT', 'NaCl or something'); // salt for crypto hash
define('TIMEOUT',14400); // max time limit on form
$timestamp=time();
....
$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).'"
name="check">';
 ...

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. 

[toc] | [prev] | [next] | [standalone]

#14277

On 10/2/2014 9:38 PM, GS wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
>> On 9/30/2014 11:33 PM, Richard Damon wrote:
>>> On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
>>>> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>>>>> 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
>>>>>
>>>>
>>>> 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).
>>>>
>>>
>>> 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). 
>>
>> 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.
>>
> 
> 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
> while. 
> 
> define('SALT', 'NaCl or something'); // salt for crypto hash
> define('TIMEOUT',14400); // max time limit on form
> $timestamp=time();
> ....
> $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).'"
> name="check">';
>  ...
> 
> 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. 
> 

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.

Jerry
-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14278

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

> Actually you can do it with hidden fields, effectively turning a form
> into a giant cookie.

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 
vectors.

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, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14280

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):

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

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

  if(!file_exists($file))
    {
      file_put_contents($file, '');
    }

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

  if(isset($users[$_POST['id']]))
    {
      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 = '';

if(!empty($_POST))
  {
    try
      {
        register();
      }
    catch(Exception $e)
      {
        $err = $e->getMessage();
      }
  }
?>
<!DOCTYPE html>
<html>
  <head>
    <title>Registration</title>
  </head>
  <body>
    <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'>
    </form>
  </body>
</html>

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14282

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

> 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).

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, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14283

Denis McMahon <denismfmcmahon@gmail.com> writes:

> On Fri, 03 Oct 2014 00:24:01 -0400, Matthew Carter wrote:
>
>> 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).
>
> 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.

"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 (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14284

Matthew Carter wrote on 10/3/2014 3:16 PM:
> Denis McMahon <denismfmcmahon@gmail.com> writes:
>
>> On Fri, 03 Oct 2014 00:24:01 -0400, Matthew Carter wrote:
>>
>>> 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).
>>
>> 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.
>
> "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.
>

Coherent, terse, functional and likely true.

+1


-- 
Ed Mullen
http://edmullen.net/
Do Lipton employees take coffee breaks?

[toc] | [prev] | [next] | [standalone]

#14285

On 10/3/2014 4:16 PM, Matthew Carter wrote:
> Denis McMahon <denismfmcmahon@gmail.com> writes:
> 
>> On Fri, 03 Oct 2014 00:24:01 -0400, Matthew Carter wrote:
>>
>>> 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).
>>
>> 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.
> 
> "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.
> 

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
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14257

In article <844d52dc-57de-48bc-8d61-ef12d7696389@googlegroups.com>,
 Apple Sizat <afor6993@gmail.com> wrote:

> 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

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]

[toc] | [prev] | [next] | [standalone]

#14258

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

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

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

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web