...

View Full Version : access logger



Aymen++
04-15-2004, 02:16 PM
how can i make many pages no body can access them except the autherized persons?
or how to make access logger?

zigo86
04-15-2004, 02:37 PM
These are two TOTALLY seperate things!

For restricting access, use a login form and php sessions, at the top of each restricted page check their session - logged in cool, not logged in bugger off.
Check sessions in php manual!

For logging, just run an insert query every page and dump some info in a table.

zigo

Aymen++
04-15-2004, 02:41 PM
when i wana use session variables, what should i register in these variable? the username and password or only the username or none of them?

zigo86
04-15-2004, 02:50 PM
After the login form

1. Check the username and password against those in the DB

2. If match,


$_SESSION['valid_user'] = $_POST['username'];

3. Then check every page:


if(!isset($_SESSION['valid_user']))
header("Location: buggeroff.php");

Then out put the rest of the page.

You may want to give them a message if there username/password didn't match DB.

zigo

me'
04-15-2004, 03:12 PM
A more secure way than relying on HTTP header relocation would be to die();.
if(!isset($_SESSION['valid_user']))
die('Please login to view this page');

zigo86
04-16-2004, 12:50 AM
Yeah! Good call, me'!

If your going to redirect them, put exit() straight after header() call!



if(!isset($_SESSION['valid_user']))
{
header("Location: buggeroff.php");
exit();
}

Scrowler
04-16-2004, 04:12 AM
i dont use header() any more, i couldnt be bothered with "headers already sent on line...." so i just use:

echo '<script>location.replace("page.php");</script>';

works fine for me :)

me'
04-16-2004, 10:50 AM
i dont use header() any more, i couldnt be bothered with "headers already sent on line...." so i just use:

echo '<script>location.replace("page.php");</script>';

works fine for me :)Even less secure, what if someone has Javascript disabled? Plus you need a type attribute on that script,
<script type="text/javascript">...</script>

raf
04-16-2004, 11:01 AM
i dont use header() any more, i couldnt be bothered with "headers already sent on line...."
Realy.

Maybe something is wrong with your coding-logic, if you wan't to redirect the client to another page, after output was sent to that same client :rolleyes:

Aymen++
04-18-2004, 12:07 PM
what is the difference between:
session_register("username");
and:
$_SESSION["something"]=$username;
?

Aymen++
04-18-2004, 01:45 PM
is it secure that we use the session variables? i think anyone can set the session variables and log in, just by the knowledge of the username of someone, is it right?

i read in one book about making access logger,it checks for the username and password first, then calls this:


setcookie("auth", "1", 0, "/", "yourdomain.com", 0);

and in the beggining of the secret page:


if($_COOKIE[auth] == "1")
You are authoraized.
else {
header("Location: somepage.php");
exit;
}

so, should we check with session variables or with cookies?

raf
04-18-2004, 02:19 PM
what is the difference between:
session_register("username");
and:
$_SESSION["something"]=$username;
?
session_register("username"); will only work on servers where register_global=on. $_SESSION["something"]=$username; will always work and is what i would recommend to always use.

is it secure that we use the session variables? i think anyone can set the session variables and log in, just by the knowledge of the username of someone, is it right?
No. It's not that simple to set sessionvariables. But it's also not completely impossible. A bigger related securitythreath is session-hijacking. If you manage to steal a sessioncookie or the SID from aother user, then you automatically can request pages and this other persons session-variables would be used, and possibly disclose sensitive information to you. But since http is a stateless protocal, you need something to identify the requesting client with, hence sessions.
To reduce securityrisks, you can keep 'session-info' inside a db, where you keep a sessiontable that also checks for the IP and possibly a persistent cookie + you can use session_regenerate_id() on each request to reduce the risk of sessionhijacking + you could use SSL and other encryption-methods to secure your communication + use a Kerberos ticketting-service or something similar.
(That is, after you made sure your code itself doesn't have security-issues...)

<edit>
Sessions are securer and more universal then a persistent cookie. This code basically reinvents one of the most common uses of sessions.
In my opinion, using a db and checking on both the SID, the IP and a persistent cookie is still the most secure way.
</edit>

Aymen++
04-18-2004, 02:25 PM
thank you very much.
and what about this:


i read in one book about making access logger,it checks for the username and password first, then calls this:
Code:
setcookie("auth", "1", 0, "/", "yourdomain.com", 0);
and in the beggining of the secret page:
Code:
if($_COOKIE[auth] == "1")
You are authoraized.
else {
header("Location: somepage.php");
exit;
}
so, should we check with session variables or with cookies?

firepages
04-18-2004, 03:32 PM
whilst the `some users won't have cookies` argument is not really a good one it is certainly occaisionally true , sessions are far more secure anyway , e.g. its far easier to forge/steal a cookie than hijack a session.

Sessions are useful for so many things that its well worth getting to know them.

misterx
04-19-2004, 12:34 AM
I like to md5() the password before storing it in the session. Maybe I'm just fooling myself but it feels more secure.

raf
04-19-2004, 12:38 AM
why would you store a pwd inside a sessionvariable?

misterx
04-19-2004, 01:51 AM
why would you store a pwd inside a sessionvariable?

Because I don't want the authentication on each page to simply be a matter of whether or not there is a username in the database that matches the username stored in the session.

First there has to be a username in the DB that matches the one stored in the session. Then the password that corresponds to that username in the DB also has to match the one stored in the session(after being hashed by md5()).

Maybe it's needless with sessions but back when I used cookies I was only storing the username and a friend of mine was able to get into the system because he knew my username and was able to create a cookie that passed the test.*shrugs*

firepages
04-19-2004, 05:34 AM
because he knew my username and was able to create a cookie

... now imagine he hijacked your session .. unlikely but still possible , MD5 hashes can be brute-forced in a matter of minutes offline (psuedo-salting of the hash may help )

Yes your session is probably still safe but now your mate has a password that 1) allows him/her to login & start a new session and casue havoc;) and 2) may well be useful elsewhere ~

As raf alludes there is no need to ever store passwords anywhere but in the database (or password file) , the existance of your auth session in the first place should be enough to validate.

misterx
04-19-2004, 06:04 AM
Well, that makes sense. Thanks for the advice. :thumbsup:

I think I might actually try to implement that storing the SID in the DB while the session is active method that was mentioned earlier.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum