Thread: Transaction including two web page + timer
Dear All: I have a question of, when users input some contents in the second page, then the contents in first and second pages are inserted into tables; Otherwise, rollback. I want to use transction to handle it. But when users input the contents in first page, how do I know users have left( My program will roolback ) or want to continue input sone contents in the second page (comit)? Usig timer, for example? or some other better idea. Thanks. Zhidian Du _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
On Sat, Nov 09, 2002 at 00:04:26 -0700, Zhidian Du <duzhidian@hotmail.com> wrote: > > I have a question of, when users input some contents in the second page, > then the contents in first and second pages are inserted into tables; > Otherwise, rollback. > > I want to use transction to handle it. > > But when users input the contents in first page, how do I know users have > left( My program will roolback ) or want to continue input sone contents in > the second page (comit)? Usig timer, for example? or some other better > idea. My suggestion would be not to start entering either page until the application has all of the data for both pages. Holding transactions open for long periods of time is not a good idea.
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? Thanks. Z. Du >From: Bruno Wolff III <bruno@wolff.to> >To: Zhidian Du <duzhidian@hotmail.com> >CC: pgsql-php@postgresql.org >Subject: Re: [PHP] Transaction including two web page + timer >Date: Sat, 9 Nov 2002 09:59:04 -0600 > >On Sat, Nov 09, 2002 at 00:04:26 -0700, > Zhidian Du <duzhidian@hotmail.com> wrote: > > > > I have a question of, when users input some contents in the second page, > > then the contents in first and second pages are inserted into tables; > > Otherwise, rollback. > > > > I want to use transction to handle it. > > > > But when users input the contents in first page, how do I know users >have > > left( My program will roolback ) or want to continue input sone contents >in > > the second page (comit)? Usig timer, for example? or some other better > > idea. > >My suggestion would be not to start entering either page until the >application >has all of the data for both pages. Holding transactions open for long >periods of time is not a good idea. > >---------------------------(end of broadcast)--------------------------- >TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
On Sat, Nov 09, 2002 at 14:03:50 -0700, Zhidian Du <duzhidian@hotmail.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.
--- Zhidian Du <duzhidian@hotmail.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? > What about passing the values of form1 to form2 and storing the values passed from form1 to form2 in inside the <hidden> fields? ludwig. __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
> > 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. brew
On 10/11/02 2:29 pm, "brew@theMode.com" <brew@theMode.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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Adam Witney wrote, On 11/15/2002 4:40 AM: > On 10/11/02 2:29 pm, "brew@theMode.com" <brew@theMode.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.)
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.