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 22:26:11 +0530 (IST) > > 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 ... > I think your choice of machines is good. The way I would set them up: Internet connection comes in, goes through a firewall to the web server. The web server has two network cards, the one connected to the 'net is given an IP address supplied by your provider. The second network card is connected via a hub, or a crossover cable to the database server. The IP addresses on this link are selected from RFC1918. 10.x.x.x, 192.168.x.x, etc. and are not accessable from the Internet. |------------| |------------| | | | | Internet -------- | web server |------------| database | via firewall | | internal | server | |------------| network |------------| Configure your web server so it does NOT forward IP packets. The bad news, you can no longer access your database server directly from the Internet. The good news, neither can hackers. They have to get control of your web server before they can start to attack the database. If you have someone near the servers most of the time, it should not be a problem. If you must access the database server from the Internet make a SSH connection to the web server, then connect to the database server from there. > > > yep i am using HTTP authetication .. are there special precautions to > take using this with php... > Just don't expect too much from it. It is a simple protocol, and no consideration has been given to closing or changing logins without exiting the browser. All I can say is don't make any grand promises about logging people off, or letting them change who they are logged in as. The only thing that usually works is to exit the browser. It is good enough for most people, just not great. If you want to have customers connecting from public browsers at the local library it can get messy, unless they exit the browser, but the usual case of people who dial up, or people who have a full time connection to the Internet it works well enough. > > 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 ... Mostly so you don't have to worry about keeping track of several different syntaxes. I think once you get used to DB access via PHP you won't want to figure out how to do it in another language just for your background processes. The CGI version of PHP works just like Perl, you use something like #!/usr/bin/php -q in the first line instead of #!/usr/bin/perl -w. > actually i have compiled php as apache module .... which one is better > .. the CGI one or the module one??? > MODULE!!! By far. CGI requires a process to be spawned for each incoming request, the module just parses the php code and executes it from the Apache process that is already running. Since Apache keeps a pool of processes waiting, your visitors don't have to wait for even the initial Apache process to be spawned. Sub second response times for dynamic pages is possible! > > 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 ... > There is GREAT documentaion at www.modssl.org Once you have modssl setup, you effectively have two web servers, one for secure traffic, and the other for non-secure traffic. They run off the same physical server, but the configuration and content are as separate as any other Apache VirtualHost. Any content you place in the secure DocumentRoot is sent secure. The setup may take a day or two the first time, but once it is setup it is almost transparent. > > > > > 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 full control of your server, I suggest you don't use htaccess files for anything. Just allowing .htaccess files requires Apache to look to see if the file exists in the directory of each page served. If it does exist the .htaccess file has to be parsed, as a part of EVERY page request in that directory. Everything you can do from .htaccess can be done from httpd.conf / srm.conf / access.conf pretty much with the same syntax. The difference, the Apache configuration files are parsed once when you start the web server, or when you send it a HUP or USR1 signal. The bad news, you have to remember to tell the web server to re-read the configuration files each time you change them. (apachectl restart, apachectl graceful I think) The good news, you have shaved the time it takes to parse your .htaccess files off of each visit the site gets. You do not have to restart or reload the server for changes in the access lists you setup. Adding an access list to a directory requires a restart, but the access list file is read each time it is used. On my servers I did not compile in the code to manage .htaccess files. It is a ./configuration option. I'd have to dig out my notes to tell you exactly which one. While I'm on the subject of ./configure, I am a minimalist. I believe that if it isn't there it can't break, or be used by a hacker to break in. I've gone through my server configurations, and the ./configure options on the programs I compile and eliminated everything I don't think I am going to use. > > 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 are outside the US, just grab Mod_SSL from the address above and follow the instructions in the INSTALL file. If you are inside the US, and need it before Sep 20, when the RSA patent expires, you probably need to buy a commercial SSL server. Red Hat has a good price. Ralf has some of the best looking documentation I've seen, open source or not, on his mod_ssl site. The mailing list is very good too. > > 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??? Yes, I am a strong advocate for SSL. Hope this helps... Rick Widmer Internet Marketing Specialists www.developersdesk.com