Addressed to: "Simon Garner" <[EMAIL PROTECTED]>
"Chris" <[EMAIL PROTECTED]>
"php" <[EMAIL PROTECTED]>
** Reply to note from "Simon Garner" <[EMAIL PROTECTED]> Fri, 2 Mar 2001 13:05:00
+1300
>
> So how do you verify that the logged in user is allowed to act on behalf of
> the other ID? You just have to keep reverifying that the client is allowed
> to do what they're doing.
>
I suggest it is time to take a look at sessions:
http://www.php.net/manual/en/html/ref.session.html
Things get easier if you only allow a small group of people into the
site. You won't be able to keep someone who knows a valid username and
password from exploiting things, but you can limit the possible exploits
to what you allow a user to do.
I suggest you use a SSL secured server any time you are sending
passwords across the net. That way they can only be intercepted by
someone with access to the authorized user's machine, or someone with
access to your machine. SSL is not magic, all it does is prevent
someone along the way from snooping.
When someone enters a valid username and password, create a session and
store all the temporary data on the server. If it is never sent to the
browser, there is no way for someone on the other end to modify it. A
PHP session ID is a reasonably secure random number that is hard to
guess. It is even harder to guess the session ID, user name and
password all at the same time.
That still does not stop me, a valid user who can use the system from a
browser, from being able to write a script that fakes my user action.
It does allow you much more control to make sure that neither me or my
robot are able to do anything you don't want me to do.
> It's a chore I know - security usually is :(
Yep!
Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
