Multiple websites, single registration - best practice

[colebq]

Hi,

 

Going to make a project with multiple websites where websites might exchange specific content. Also there will be one registration for all websites. Registering to one website lets you login to the other website with the same login data. Here is an illustration:

 

 

I am thining of what might be the best approach to do this. Maybe using SOAP, and having the Members part run as a web service?

Using Zend Framework. I am not sure how performance effective SOAP requests are because all this will run on the same machine.

 

Any suggestions are welcome.

 

Thanks

 

p.s. another example for above: Foo.com sells books. Bar.com is some portal. Both use same member accounts. Bar.com aditionaly gets data from foo.com to sell their books through the bar.com website.

[requinix]

Ah, I'm having fun thinking of all the cool things you could do with this...

 

But the simplest for user registration would be to have one place expose an API that allows someone to register and lookup a user. Foo and Bar send signup and login information there and get some response in return. For login particularly, the sites can store locally whatever site-specific information they want and publish to the service any information that should be shared; on login they can create whatever default information if the user doesn't exist in their systems yet (because they signed up somewhere else).

 

For sharing information use more APIs. These could be as simple as RSS feeds (with or without authentication) - the best solution I know for your "displaying articles from Bar" requirement. Books would be a little more work because you wouldn't want a feed of everything.

Then you start going into details like having users on Bar automatically buy stuff on Foo - which is a poor example because Foo would surely rather have users visit their own site for purchases, even if just during the checkout process.

 

SOAP is just a protocol and means of transferring information. you don't have to use it: XML (raw XML, RSS, SOAP, etc.) and JSON and text and whatever are also options. Authentication can be done in any one of a billion ways if needed.

[colebq]

Hi,

 

For this example let's say foo.com and bar.com belong to the same company so its not important where they sell the product.

 

Another question would be how much would such API calls impact on server performance if the information is fetched through, soap, xml, json,...

 

When a user opens up a single page there might be multiple API calls. ie. call to the Login service, call to foo.com to fetch book lists, etc..

and because the calls are going through the HTTP protocol that means that each time an Apache instance would be started to serve the request.

 

Would this approach be safe or is there some more efficient method which would be less demanding on server performance. I have not built something similar yet thus my questions about performance.

 

Everything is gonna be on the same server having multiple domains configured.

[Philip]

I've heard good things about CAS (Which includes a PHP lib) - but I can't say I've ever used it.

 

I'm curious to know what your end result is, because I've always foudn this topic interesting

[Jumpy09]

If the websites are on the same machine and running under the same instances of PHP / Apache / MySQL then you could go another route all together.  Under the assumption that the websites would be run in coherence with one another as if you placed 3 websites in a single Shared Hosting Environment, instead of each in their own Shared Hosted Environment, the websites could communicate with each others databases directly through php or whichever programming language you are using.

 

For example since they would be located on the same machine using localhost for all Database Calls would be allotted as they are all hosted under the same localhost.  Foo.com accessing the Database using 127.0.0.1 or localhost would access the same Database as Bar.com using 127.0.0.1 or localhost.  You would only need to access the specific databases to pull the information from them to display on each of the websites.

 

If they are on the same machine / localhost, you have three options as to how you go about setting up the Database.

 

#1: One Connection / One Database for both sites to utilize together coherently.

#2: One Connection / Three Databases for each specific purpose / site.

#3: Three Connections / One Database per Each Connection, granting the Foo.com, the Bar.com, and the Linked Accounts each their own Connection.

 

#2 and #3 I would suggest using a unique Username / Pass for the Connection to mitigate any totalitarian access in the horrible event someone was able to maliciously gain access to one of the Usernames and Passwords.  This would protect each individual Database to mitigate potential catastrophic effects from the exploitation of 1 site.

 

Just use multiple connections to access the specific portions you need, which will run everything under a single Apache process to help with your Performance concerns.

 

Of course if you are aiming to separate the sites in a method that each would run from a separate Shared Hosting Platform, then this method would not quite work out very well.

 

I know you can give cPanel Accounts Dedicated IP Addresses / their own specific IP Address, but I'm unsure if this is possible on a closed loop manner as well.  For instance 192.168.1.115 is inaccessible from the Internet, so if you could give each site its own Local IP Address instead of a Global one, then it would be possible to use the same methodology behind the scenes in the situation that each website had its own closed / jailed set-up.

 

Sorry if my wording is off and this is under the assumption that PHP is run as an Apache Module or you are running all of the sites in the same htdocs folder.  If you plan to expand to allow remote websites to also access the Database which would not be located on the Server / Machine hosting the databases, then this would not really work out very well.  Hopefully I made the right assumption and if so, there would be no reason to treat each website like they are on separate machines unless your Long Term Plan is to eventually have them on separate machines.

 

If you are going separate machines, AJAX actually isn't a bad method which uses Javascript and Server Side Programming together.  Make sure you have a nice hash value per user that changes each time a user logs-in and send it ( hopefully over HTTPS ) to the Server in Question it utilizes everything on that machine and sends you back whatever you need it to in order to provide functionality.  Good part about AJAX is that you can move one site to any server in the world and the functionality will always work without doing a lot of back end setup.  I've never personally used CAS. but it does look somewhat promising.  Downside of AJAX is you open the particular file open to be directly accessed, so you would need to set up enough security to ensure only legit / valid users are able to access the processes within the files.  AJAX does somewhat increase bandwidth usage where as hosting all the sites / databases on a single server wouldn't.

 

Hopefully this is helpful.

[colebq]

Hi Jumpy09, thx for the reply.

 

I am familiar with the technologies so there shouldnt be problems implementing them.

 

I want to try to avoid direct database access from different applications. I just dont like the idea of  applications having much direct contact with the databases of other applications. This would also require of having to write librires for them to use, so any changes to the original system would require updating code in the "guest" applications libriaries.

 

Having an API and serving the data through a webservice sounds better becaue that way the applications are totaly seperated.

 

I have no experience using web services so what I'm asking is whether it is efficient to use SOAP, JSON,.. / HTTP to share data between the web sites when there are multiple web services calls for a single page load. And because the web sites sit on the same server I was wondering if  SOAP... / HTTP  communication is ok to use or if there is some other method of communicating with web services that is less demanding on server performance.

 

 

[Jumpy09]

API or Library Files would work on the same principal that if you update 1, the other is updated.  No need for redundancy or duplicate files spread all over the server.

 

I want to try to avoid direct database access from different applications. I just dont like the idea of  applications having much direct contact with the databases of other applications. This would also require of having to write librires for them to use, so any changes to the original system would require updating code in the "guest" applications libriaries.

 

You still have to create separate files for the API Utilization through each of the "Guest Sites", so any changes to the Original System would still require updating code in the "Guest Site" API Files found in the Main Site / Application.

 

---

 

For Data which the Sole Intent is for Display Purposes only and not for Authentication, Validation, or relied on to determine what a script will be doing can be sent in HTML or XML over HTTP / HTTPS Protocols through either JSON or AJAX without really serious Security Risks.  I would always use HTTPS to transfer any Data from point to point to prevent Eavesdropping / Man In The Middle.

 

If you want to set up the Account Authentication, Validation, Verification, and all that as a Web Service I am really interested in what Security Implementations you would be developing to maintain Authenticated Session Control between the Account Web Service and all the Processes / Actions found on the Site that requires a valid Log-In / Session to perform.  Will you be allowing the Same Sessions across both sites, or will each Session Management be separated?  Direct Access gives you Optimum Security if you set it up right, I can only imagine how any shotgun shells / machine gun drums that you will be unloading or blowing through your Website's Security by utilizing an Account Web Service.