Re: lots of session & POST thingy

Addressed to: Subhrajyoti Moitra <subhra@iitk.ac.in> php-general@lists.php.net ** Reply to note from Subhrajyoti Moitra <subhra@iitk.ac.in> Mon, 3 Jul 2000 13:12:42 +0530 (IST) > > > this thing kind of worked .... but that means i have to send the ID in > each page either in the url or in hidden parameter form ... > this is going to be a pain .. Yep. > moreover i have to check at the begining of each page that the user > is actually a valid user ... which is messy .... It is... > which also means i have to recode my programs ..... but one more > thing regarding this ... doesnt it put a substantial load on my mysql > server... for each page i have to check whether he is a valid user or > not ... Welcome to the world of dynamic web design. You are trying to do things with HTML that it was not designed to do. You get to work extra hard to make up for limitations of the HTML standard, like its lack of memory for what happened before the current page was requested. > persistent connections might help .. but still then if i about > 1000 users logged in .. what impacts will it have on the sql > server....??? Big hard drives and lots of memory work wonders. If you have complex queries, a fast processor will help, but probably the best thing you can do for your database server is have lots of RAM. > secondly once the user logs out "properly" by clicking on the logout > button i delete his entry from the table... There is 'good enough' in authentication techniques, but I won't call any of the tricks I know of great. The only reliable logout I know of is to exit the browser. Logging out cleanly, is a hard thing to do. HTML authentication sucks. There is nothing you can do about it server side. Even if all the browser manufacturers decided to fix it tomorrow, (dream on...) how long would it take before 90% of the people around the Internet upgraded? (Years is my guess... I still see > 18% of my hits from version 3 browsers.) Till everyone upgrades, you get to live with current technology. > but what if he doesnt ... > he just kills the browser ... the session is dead but the the database > still holds the ID and info .... in course of a time.. i need to clean > up my databse ..... this is a bigger pain .... Welcome to the big leagues... That is what you get the big money for. On Unix/Linux/BSD you have a friend called cron. You can compile PHP for CGI/Standalone mode and execute php scripts on a schedule from cron. For example, each day at midnight you could have a script to destroy all sessions that haven't been accessed in 48 hours. That way someone could keep a session alive by working with it daily, but if they go away two days or more they have to start over. You can set the time limits pretty much any way you want. > what does experts suggest i do in this case . please .. i need this > badly ... please ask questions to clarify .... Use Linux, Apache, PHP4, MySQL, and mod_ssl. If you can't handle everything on one machine, split the database and the web server(s) and provide a separate network between the web server(s) and the database server. Get used to the fact that you will be sending a session ID, either as a cookie or in the URL of every page you link to in your site. That is why I suggest PHP4, it includes session support 'out of the box.' If the idea of handling user authentication in every script bothers you just place all your scripts in a directory, and put a password on that directory using Apache. Another advantage of this is your users will probably have seen it already. If you 'roll your own' authentication your users may have something else to learn to use your site. Users hate having to learn new stuff, or think. If you have any reason at all to protect your data with passwords, go all the way and protect it with SSL encryption. All you have to do is configure a VirtualHost for all your sensitive data, and run it through SSL. There is no difference in how you write your scripts, it is all in how you configure Apache. You will want fast processors, or even hardware accelerators for your SSL machines. If you think a password protects your non-secure pages, think again. It is sent in clear text with every page request. Anyone who can sniff packets between your user and your server can read the passwords out of the data stream, no problem... Just remember, if it was easy, anyone could do it. They wouldn't have to pay you. :) Rick Widmer Internet Marketing Specialists www.developersdesk.com