Re: lots of session & POST thingy

now this is what i call a wonderful reply .... thanx php3... well all these clears a lot of doubt in my mind .... but at the same time it raises a lota questions also .... can u just take a little more of your time to clarify those ... thanx again... > 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. i have at my disposal two machines.... both PIII's 700 MHz... pc-1: 256 MB RAM 13.4 GB HDD pc-2 128 MB RAM 10.4 GB HDD what i have decided is like this .. pc-1 acts as my database server and pc-2 as my webserver.... ?? please advice ... > > 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. > yep i am using HTTP authetication .. are there special precautions to take using this with php... > > 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. why use php for the purpose ..?? i can also do the same with perl or for that matter a shell script will do the job....i think so ... actually i have compiled php as apache module .... which one is better .. the CGI one or the module one??? > > 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. i have no idea how to use mod_ssl with apache .. i will try to figure out that tonight .. yep i think the above configuration is simply awesome ... > > 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. i think one does this by using .htaccess file in apache ... will work on it tonight .... > > 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. can u please be a little clear about how to implement encrypt data using SSL ... > > 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... i think this is a problem since the inception of the internet... just that there were less sniffers.. probably.... what do u suggest i do in this case .. encrypt i guess??? > > > Just remember, if it was easy, anyone could do it. They wouldn't have to > pay you. :) i understand it completly .. and thanx for reminding me again .... thanx a lot for all the clarification... subhro..