Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #14276
| From | GS <nomail@nospam.org.invalid> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: Php login/registration page |
| Date | 2014-10-03 01:38 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <XnsA3BB1AEBFA590R2D2@127.0.0.1> (permalink) |
| References | <844d52dc-57de-48bc-8d61-ef12d7696389@googlegroups.com> <m0fjdl$64d$1@dont-email.me> <ECKWv.296304$Q61.224596@fx13.iad> <m0gr5h$b0m$1@dont-email.me> |
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.
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web