Three sites-one database

[EditFast]

I have seen it happen time and again where Google determines that a Web site is located in either Canada or US (or any other country)(let's say this is determined according to the company address or the site owner's address for simplicity) and traffic then starts to come from only that country. What about those services that are Internet based and therefore not bound by country borders or time zones? How can I avoid this problem? (I am sure it is not just me).

One way I have thought of is to use .com as the main site and have sister sites at .ca and .us addresses. However, aside from the possibility of getting knocked by Google for duplicate material on the sites (my plan is to simply copy the entire site of 3000 pages rather than try to rewrite it to avoid the duplication problem) how can I manage the database so that all additions, registrations, new projects, deletions etc. are handled by one database? I want to have all three sites driven by the same database. All of these sites would be on the same dedicated server (unless I am convinced this is not a good idea), but with different IP addresses. I think these three sites should be able to access the same database.

But what will the problems be that I might run into. Can you predict any major hurdles with this system?

Your opinions will be appreciated.

[kgun]

Isn't it not enough

1. To write a database connection class (API). I think that class is already written in PEAR, so you do not need to reinvent the wheel. Then you use that class on the different sites. The PEAR connection class ought to (I do not know it in detail) take care of timeouts and server down cases.

2. It is always a good practice to store configuration information in a file and require (include) it in your applications.
3. If it contains sensitive information like passwords etc. the .ini file should be located in a directory that it is difficult to guess the name and location of and give it a cryptic name. If you know the PHP parse_ini_file function, you can parse that sensitive information (CrypiticNameConfiguration.ini file) and in that way make it more hidden to potential hackers.

[EditFast]

Thank you kgun. I am not a specialist in this field and only understand the most general of ideas related to databases (and site programming for that matter), but I like to know how things work to facilitate the decision making process and what you say seems like good advice. I will take it up with my programmer. Thanks once again.

[mikesmith76]

If it contains sensitive information like passwords etc. the .ini file should be located in a directory that it is difficult to guess the name and location of and give it a cryptic name.

This is security by obscurity (not a good idea in my opinion). If you need to store sensitive information place it in a directory outside the webserver document root, and use PHP (or whatever) to load them from this location.

[EditFast]

Originally Posted by mikesmith76

This is security by obscurity (not a good idea in my opinion). If you need to store sensitive information place it in a directory outside the webserver document root, and use PHP (or whatever) to load them from this location.

The above sound to me like the same thing in different words. Personally I think it is best to encrypt everything as well as using the steps both of you mention above.

[mikesmith76]

if you place your connection details outside of the document root there is no risk of the webserver accidentally serving those details to the public. This is in no way the same as using an obscure directory name which in my eyes offers little or no security.

[kgun]

Originally Posted by mikesmith76

if you place your connection details outside of the document root there is no risk of the webserver accidentally serving those details to the public.

That was what I said, but in addition I reccomendrd that you should use a cryptic folder name and a cryptic .ini file name.

Originally Posted by mikesmith76

This is in no way the same as using an obscure directory name which in my eyes offers little or no security.

Agree to that, but as explained above I suggested more.

If you encrypt passwords, and you have to decrypt them somewhere, a hacker man guess the decryption algorithm. You may also use PHP's md5 function to compare the encrypted version of a password with that entered by a user (technique used on most forums) which avoids the risks involved with encrypted values that could possibly be decrypted by a hacker.

Example:

cryptic.ini located in crypticfolder name

; Settings to connect to SQL
[Database_Settings]
host =
user =
password =
dbname =

; Default look of the site
[Preferences]
color =
size =
font =

ParseIniFile.php
<?php

$iniVars=parse_ini_file('../crypticfolder/cryptic.ini', TRUE)

$mysql=&new MySQL(
$iniVars['Database_Settings']['host'],
$iniVars['Database_Settings']['user'],
$iniVars['Database_Settings']['password'],
$iniVars['Database_Settings']['dbname']
);

...
...
?>

You need the MySQL class to connect to your database, where the constructor takes the password as one of its parameters that it gets from parse_ini_file. But this password is hidden in (and md5 hashed if you want) the cryptic.ini file. The cryptic.ini file may even be stored on a different server to make it even worse for hackers. Somebody even split the password and store the two halves on different servers.

Note: MD5 is not an encryption but a message digest algorithm.

Excersise 1: Simplify and make the code more secure without using security by obscurity.

Excersise 2: Simplifying or not, make the code more secure without using SSL. You may use third party classes like PEAR.

[mikesmith76]

That was what I said, but in addition I reccomendrd that you should use a cryptic folder name and a cryptic .ini file name.

My apologies kgun i guess i should learn to read!! :-)

[brian.mark]

I think you're missing one key element here.

The tld isn't what is causing most of the problems. It's the locale of the IP in many cases. If all 3 ip's are issued from the same ISP, they're all registered to the same country and will end up with rankings within the same country in Goog's eyes. Same is true of Yahoo and Live (although Microsoft seems to do this to a lesser extent.)

Best case would be hosting your sites within the country you wish them to rank for. If it's truly a global service, there are solutions like Akamai which the engines recognize as global, too. That might be a better way for you to go than setting up multiple accounts.

Brian.