Not done it, 'cos I've never had the need, but could do it...

Would need to think a little about security - are the different sites physically on the same box, or are we going to need to send plain text passwords acroos the web, in which case all sites would need to be running in SSL (or I guess we could use a secure tunnel...).

Basically, you would need some kind of web service fitted to the sites that can add / edit and delete users and when changes were made on one of the sites, it would push the changes out to the services on the other sites.

Not straight forward, but do-able...

Jon

Maybe a synchronizing service like rsync? Also, would you want only one site to be editable and then the other two display that or to have all of them be editable. IF you don't want them all to be editable something like aliasing but for seperate domains might work well.

I think using rysnc is the wrong way, you could use rysnc with logrotate to have a rotating backup scheme, but it's not been made to backup/sync databases, but files/folders.

Enabling mysql replication is obviously a lot easier and reliable than rsync.

Hey all,

Sorry for not responding sooner. For some reason I'm not getting the emails (probably should check out my junk box)

Anyway...

@jbx - Just to let you know its all on the same server so I'm not to worried about sending it all over the place (i.e. different hosts.

As for your idea, I will have to look into it a bit more. We were thinking maybe looking into the OpenID service...

@12345j - Just to let you know that the only think that will be connected is the users nothing else. So I assume that the profile pages are indeed linked to the user

@lunatik - I will look into the the password salt but I have a feeling that it wont really change anything. As for the mysql idea is probably the best so far. We were thinking about doing it. It's just a matter of figuring out how. :)

Well I am probably going to leave this thread open for anyone else to jump in (I wish there was a close button :P)

-TG

What if you could create a referee link. If you come from the right referee( any link on your site) then you don't have to log in. Or have login check for a cookie that expires 5 hours after loggin in, and is installed when a user signs in. H
Then you'd just have to have the same users; and password.

that's very bad practive 12345j!
people tend to c/p urls. This has been known as a vuln for many years.
I guess you weren't using php back then, but it was default some years ago that urls had the salt within the query string. Well good for hackers, bad for site owners and users.

I never did this, but I suppose it's all about syncing db tables ("Users" table and those used for holding profile information) and having the same password salt set up for all the sites (look at "/config/site.php")

The other option may be more elegant, but I'm not sure if it's gonna work:
Look at mysql proxy services. If you'd be able to route all the sql requests for those "Users" and profile related tables to one db for all three sites, while routing other requests to separate dbs -- that would be cool.

Sharing the salt is a good idea, but it's not all, because the site will create a cookie for domain.com, but not for example.com. Sharing cookies across domains won't work also without a policy that allows this. It's called crossdomain.xml that you've to into your root to specify cross domain communication. That opens doors and gates in terms of security.

The obvious solution is to replace the authentication provider with OpenID or LDAP, which the first is already integrated into the core, but almost undocumented. I can think of phpopenid, to setup a personal openid service. Because that's what you'll need - an authentication service. Doesn't even matter if it's external, but OpenID has one big issue, it's complex and hard to understand for regular users. The forwarding to facebook and redirection back to your site may irritate most of your site users.

LDAP is elegant, but setting up a LDAP server isn't easy as pie.
I've done that for a company already. Then we have NTLM Authentification, which is a Microsoft technology. You can use it to auth against an Active Directory Server. Perfect for Intranet and easy to use, but the hash used is weak by default. Don't know about newer NTLM versions. Microsoft calls it SPA sometimes too for Exchange.

Kerberos is good opensource solution compared to NTLM in example.
It is a bidirectional authentification technique. The server identifies against the client and the client identies against the serer, bot authenticate to each other making MITM (Man in the middle attacks) inpossible. It's well thought out and pretty secure, but more complex than all the above. Luckily you'll have mod_kerb5 in your ugly apache installs so creating a ServiceProdiver for Concrete5 will be the only task left. Nginx for example doesn't have an official solution to Kerberos, but an unofficial 3rd party modules that can be found here:http://michaelshadle.com/2010/01/17/spnego-for-nginx-a-start-at-lea... you'll need to compile it into your nginx built. Well you don't know how? Then Kerberos isn't for you.

"Don't think of this as a complex and useless post.
This is not a banal or stupid easy question that you ask."

"Keep real, this is the hardest problem in the entire IT Industry!"

You cannot get a definitive answer to this problem from me, because in 10 years people will still have to think about how the authentificate against services. Probably the internet will be more under control, so that governments offer you their long wished "Public Identification Numbers". Some sites tried to authenticate using Passport ID's because they were unique, some years ago. But it turned out that the algorithm to create them could be cracked and after that there were Passport ID generators and authentication was a problem again. The NSA/FBI/CIA used a Public/Private Key infrastructure back in the days of the cold war with MD5 hashes, it was though that it's uncrackable at that time, but today it's crackable. No let's go to your router, you have WEP/WPA/WPA2/LEAP/PEAP and a lot of other authentication protocols and providerss.

If single sign on was solved in the IT industry there wouldn't be so high fragmentation. Take a look at OpenID, even though most IT Gianst like Google and Facebook consider it as their default, it's still not accepted globably, because it's not ideal or easy.

My thoughts on this.

easy: Make it easy replicate users through mysql and share salts. Modify the cookie to allow them through different sites. That means enabling *.wildcard cookies for an entire domain.

medium: Use one C5 install for all subdomains and point them to the main site.
The Domainmapper and some custom work aswell as clever rewrite rules could make it work.

harder: Geting multiple site roots is the definitive answer, but you've to code a lot and modify many parts of the core to get this to work.