Re: Transaction including two web page + timer

Adam Witney wrote, On 11/15/2002 4:40 AM:
> On 10/11/02 2:29 pm, "brew(at)theMode(dot)com" <brew(at)theMode(dot)com> wrote:
>
>
>>>>Good idea. One problem is that HTML is a stateless protocol. How can I
>>>>let application to hold the whole contents of the first page and second
>>>>page?
>>>
>>>PHP provides for session tracking. Somehow you have to be tying the two
>>>web requests together. You could store the information from the first
>>>request as a file or in a table in the database that holds the page 1
>>>requests temporarily.
>>
>>Look into session variables, they are stored on the web server and
>>available to all the following instances of PHP scripts from each
>>particular user. It is set up with one line of code at the top of each
>>script and then you can pass the variables onto the following scripts, no
>>need to worry about the the details of file or database calls for the
>>temporary info, it's built into PHP.
>
>
> I am new to PHP, but I am trying to set up a system where a user logs in on
> one page and then does various database activities on subsequent pages. Each
> user will have their own username and password on the database.
> If I was to store the username and password as session variables... Is this
> generally considered a good idea... Or is it a security risk?
> Thanks for any advice
> adam

Grrrrrrrrrrrrrrrr! Damn reply-to not set on this list.

Since the first reply went only to Adam and thus will benifit only one
person, I'll retype it to the best of my memory and try to improve on my
original reply so others may benefit.

First, a correction to someone else's earlier comment. HTML is a
document formatting language, not a protocol. HTTP/HTTPS is the
stateless protocol in question.

Second, it would be better to store a flag that it is a valid user.
Store the username if it's necessary for tracking changes via a logging
mechanism, otherwise leave it out as well. This way if someone finds a
way of dumping session variables, you won't be giving away the keys to
the kingdom. (For example a debugging script you forgot to delete from
your production system that lists all the session variables and their
values.)
For added protection, you may even store the visitors IP address in a
session variable to make sure any would-be spoofers not only have to get
the right sessionid, but would have to spoof the IP address associated
with that session as well. (Perhaps converting it to a 4 byte integer
so anyone getting the session variables doesn't recognize it as an IP
address.)
aaa.bbb.ccc.ddd -> (aaa*256^3)+(bbb*256^2)+(ccc*256)+ddd
I'm not sure if that last bit is useful. I don't know if PHP already
has its own methods for preventing piggybacking onto another person's
session. I know it can auto-rewrite links to append the sessionid when
cookies may not be available. If such a page were emailed to another
person, would the server recognize them as the original user since the
sessionid being passed may still be valid? (I know, more a question for
a strictly PHP list as opposed to PGSQL-PHP, but security questions have
a habit of crossing boundaries.)