Re: Transaction including two web page + timer

But how then would you perform subsequent database connections? You would
have to keep asking the user for their password on every following web page?

>
> 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.)
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.