Cross-site interfacing - architectural advice needed

[eluser]rideearthtom[/eluser]
Hello,

I've run into a concept with which I have no experience and was hoping for some advice.

I've been contracted to work on a project which spans several distinct web apps with their own domains and hosting solutions. I'll be using CI. The general model is that there is a central app which acts as a payment-processing and user-authentication back-end to each of the child apps.

This central app provides administrative functionality to the client who operates the network of sites - they can perform various actions on the users and transaction-related objects. There is no public interface to this app, it's just for admin use and providing interface with the child sites.

Each child site offers a unique product/solution, and these sites won't have anything in common except for using the central app's authentication-related functionality and payment-processing functionality. On each of the child sites, the user should be able to register/login, 'buy' the product, and access product material through a user-area. The user will also need to submit profile information, and this will be different for each child site. The profile and purchase details should be stored in the central app, and at all times, the central app should remain transparent, so as far as the user is concerned they've visited the child site, signed up, paid and accessed the online materials without interacting directly with any other site.

I've already built the central app as a standalone site, with registration/login (using Redux Auth), products, payment processing, etc, and the data model is complete. I've also built one of the child sites, which simply redirects to the central app when it comes to payment. However, the client has changed his requirements and now wants the payment/auth process to be transparent so that the user never appears to leave the client site. He wants this functionality to be reusable across any number of child sites, each being related to a single product defined within the central app.

I have plenty of experience developing web apps, but no experience with the concept of cross-site authentication providers and cross-site back-end interaction. I'm having a little difficulty figuring out how to get started, where to store what, how to ensure data integrity, how to abstract varying profile information per-product/child site without creating redundancy or hard-coding it, how to provide cross-site auth and other functionality, etc.

That's the simple version, anyway. Hope someone out there can figure out what I'm talking about and offer some ideas!

EDIT: I'm not asking for a system where the user logs in and can access several domains simultaneously with that authed session - just for a single login/registration repository and functionality to be used on several other domains to register and login to each.

[eluser]nZac[/eluser]
Well this is an interesting one. Let me ask a few clarifying questions.

1. Does each child site hold all of it's own products or does the parent site have a master DB?
2. The parent site authenticates the user on the child site?
3. Can child site access parents sites DB or are you running it as the parent servers the child the information?
4. Is it going to be AJAX ran?

Just some questions to clarify for me.

Cheers

[eluser]rideearthtom[/eluser]
Answers:

1. Each child site represents one or more products. Products will have certain common properties, for example price, which need to be stored in the master DB, but each product will also have numerous unique properties. Think of the 'product' as anything that can have a value attached and purchased - it might be a set of services, a download-access area, a tangible object, a visit from a professional, etc. The user-account interface and functionality for each child site will also need to be unique, except for the registration/authentication part. Hence the difficulty in deciding how to abstract the data model and where to store what.
2. Yes - for example, the user is given a login/password by the system admin, which is stored in the central db, and he/she can then use these credentials to login to any of the child sites and 'buy' the product that it offers. Likewise, a registration on any child site can be reused on any of the other child sites, though in reality this is an unlikely scenario, but the admin needs all of the registered users, their details and their purchases available in one place i.e. the admin back-end of the central app.
3. This is still an outstanding question I have with the client. I am sure that hosting all of the sites on a single server makes the most sense as cross-site DB calls can be executed securely. However, just in case, I'm thinking of the other scenario, where this functionality would be exposed without any direct DB access.
4. I'm not tied to any particular style of implementation, but as this is a prototype project for the client I guess that AJAX isn't a necessity (unless it is, if you get my drift!).

Cheers!

[eluser]rideearthtom[/eluser]
Back to question 3, I think I've convinced them to use a single server to host all the sites, so direct DB access should be possible.

[eluser]tomcode[/eluser]
I would work with an XML service which can be used by either the sites via cURL or the clients via AJAX.

That way, whatever Your client wants now or in future, Your base architecture will hold the shock.

There might be simper solutions, but I'd use OpenID for the identification, codeigniter-openid-library