tags:

views:

31

answers:

1

I have a php-based website that uses SSL and requires a a user to login before accessing any page. I would like to allow access to this site from another domain, so that the functionality remains the same, but the look, feel and domain changes for the user (with the added advantage that I have to maintain only one version of the code).

Having done some reading, I'm using readfile() function calls in php files on the secondary server to corresponding files on the primary server. For example, the login.php on the primary server is accessed from the secondary server by a file called login.php containing readfile("http://www.primarydomain.com/login.php") (and nothing else).

Now the problem - I can't even login! The login page appears fine when called initially, but when login user and pwd are entered and submitted, it's as if the remote server doesn't see the $_SERVER['REQUEST_METHOD'] variable that triggers form processing and just loads as an empty form.

Any ideas what I'm doing wrong or what configuation I might need to change?

Thanks!

A: 

Creating a single PHP file and then using it for the same purpose across multiple sites is a great idea. However, the ways in which that file can be used in this manner depend on the general infrastructure of your hosting package.

If you have a single hosting account, which allows for the hosting of all of the affected sites under the one account, you should be able to call the common file (in this case login.php) using the include() or require() functions.

<?php
require( '/home/1234/public_html/common/login.php' );
?>

In which case, all of the functionality of that PHP file will be executed as if it were a part of the calling page.

If you have multiple sites across multiple hosting accounts/servers, the above is no longer possible. Using a readfile() function would be able to gather the output which would be seen if the URL was accessed through a browser, but the underlying functionality will be lost - ie you could not call the login.php file and have it actually perform a login on the secondary site.

In that instance, you would really need to take a copy of the actual PHP files and place them on the secondary server/account to use them.

That may make it slightly harder to manage the versions of the files, but, that is a common way to handle this issue and it does work well so long as you remember to push any file updates to all affected sites.

Lucanos
Thanks for that info.In response, the secondary site will not be managed under the same hosting account - it was my intention to allow a client to access the primary site using this means and to apply further checks during login to prevent access from an "unauthorised" IP (anything not from my client).Perhaps it's possible to do what I need using a context variable as suggested by Andy's comment - I'll look into this further to see if it's possible. Alternatively, is there another way to "include" the code from the primary site so that when executed it sees the all the variables?Thx
ColmF
Meant to add - I'd prefer not to allow the client to see the php code if possible, hence me trying this approach.
ColmF
It's a nice idea, but impractical. Between increasing the risks of downtime (all your client sites are reliant on your server remaining up and accessible at all times) and reduction in efficiency (all of your pageloads where this is done have the added delay of the relayed request to your central server), and a million other bad side-effects. Add to that possible contractual clauses you may breach by never actually delivering the purchased code. If you worry about your code being re- or mis-used look at PHP Obfuscation - http://www.google.com.au/search?q=php+code+obfuscation
Lucanos