Central Registration System

[ManagerJosh]

A central registration system would be most appreciated. This way I can hook several XF forums together to power a small network of forums . Or any future XF products

 

[tmb]

Yeah its just frustrating as we are just finishing building our SMF importer and have finished a large custom mod of xen and now we are moving onto the network system we are building out. If we had a word even in private that we can expect it this year in 1.1 or whatever then we will hold off on the very extensive and expensive system we have begun to investigate.

 

[foiovitor]

This is something I expect for years in VB.
In last months I buy 2 IPB licences to try IP.Converge but don't work as our network needs - with Converge we need to do a new registration in each forum/community...

If any programmer can work in this role to XF and given an assurance that be able to withstand the addon in the future, I am willing to pay for it.

 

[Tomble]

I also think this could be a good idea. It doesn't need to be particularly grand or fancy, just something which allows XenForo forums to share logins between them, and have a relatively friendly way for third party systems to use it as well.

 

[Rigel Kentaurus]

Certainly, it could be over engineered very quickly, just sharing logins should do A basic check master forum for user, check child

 

[J2A]

Well, motivation for the developers should be there. If people want a multiple install license this would pocket them a major increase in revenue.

Already thinking of buying another 6 licenses. Please do this.

 

[Rigel Kentaurus]

Well, motivation for the developers should be there. If people want a multiple install license this would pocket them a major increase in revenue.

Already thinking of buying another 6 licenses. Please do this.

+1
please do this

 

[PoLiZe]

I love this idea

+1 !!

 

[Digital Doctor]

jfusion.org probably could tie together multiple xenforo's.

 

[ManagerJosh]

So my meeting with Kier brought up several interesting use cases that needs to be flushed out. Community feedback needed and is a must if we want this:

3 major use cases
1) Registration: How do we do registration?
2) Updating a Profile: How does a user update a profile?
3) How is information managed?

For both questions, how does a user do so? By going to different site? A centralized site? Or is it done at a local site?

 

[Rigel Kentaurus]

So my meeting with Kier

Showoff

1) Registration: How do we do registration?

My design would be that a forum can be enabled as a "master". In this mode the forum is willing to, via a private API, provide information about the users. Other forums then can register to use that information.

A "slave" forum can be configured. In this mode, you have to input the URL of the master forum and the private key. Whenever a user tries to register, it will query the master first, to check if the username is already taken. It will then use the private API to register on the master, and also to create a local account (as that would be needed for all the joins anyway).

Logins then can be a two step process. Local then master.

There is a problem in consolidating two different users in the same forum. In that scenario, local should always win.

2) Updating a Profile: How does a user update a profile?

This gets a lot trickier. My first approach would be .. keep the profiles local. Users may not want the same signature and not even the same information in all the forums they visit, and really, I think we could just start with a single sign-on

That said ..
The slave forum can just query the API to update the information in the master whenever it is updated it locally. The problem with this is that this would either require
1) Some set of push mechanism from the master to the slaves to inform them that the information has been updated, or
2) A cron job from the slaves to pull the master at intervals to fetch updated information

3) How is information managed?

My first approach is... do not make the user leave the site. Especially since it can be done locally and handled in the background. Some simple APIs can be used to replicate the information.

 

[ManagerJosh]

Showoff

My design would be that a forum can be enabled as a "master". In this mode the forum is willing to, via a private API, provide information about the users. Other forums then can register to use that information.

A "slave" forum can be configured. In this mode, you have to input the URL of the master forum and the private key. Whenever a user tries to register, it will query the master first, to check if the username is already taken. It will then use the private API to register on the master, and also to create a local account (as that would be needed for all the joins anyway).

Logins then can be a two step process. Local then master.

There is a problem in consolidating two different users in the same forum. In that scenario, local should always win.

This gets a lot trickier. My first approach would be .. keep the profiles local. Users may not want the same signature and not even the same information in all the forums they visit, and really, I think we could just start with a single sign-on

That said ..
The slave forum can just query the API to update the information in the master whenever it is updated it locally. The problem with this is that this would either require
1) Some set of push mechanism from the master to the slaves to inform them that the information has been updated, or
2) A cron job from the slaves to pull the master at intervals to fetch updated information

My first approach is... do not make the user leave the site. Especially since it can be done locally and handled in the background. Some simple APIs can be used to replicate the information.

How about in the case where you have MULTIPLE slave forums? Now what?

 

[Rigel Kentaurus]

How about in the case where you have MULTIPLE slave forums? Now what?

This model works with multiple slaves forums at well. You have a race-condition in which two forums want to register the same user, and the two of them get at the same time to the master, but that is an edge case.

Other than that, you can have N instances of slave forums connected and syncing to the same master without any issues. The first time the user that registered from Slave A tries to login into Slave B, the data would already be on the master, so this works transparently. In this model, the master always holds a copy of all the users for all the forums, but the slaves only hold copies of the users that have logged in or registered by that forum.

I have seen this working far a lot better than trying to do a peer to peer mechanism, in case someone is wondering. For reliability concerns I would probably have redundancy on the master or a multi-master strategy instead.

 

[Rigel Kentaurus]

What about when implementing the "mod" it simply creates mySQL views of the relevant tables from a master db...this would share the same user data across all slaves...the only thing then is single registration/login/logout which can be achieved through a hidden iframe...just a thought

The problem with MySQL views is that they pretty much assume that you are using a single server. That should not be the case. I would very much need this to work even if the two XenForo instances are in different servers in different parts of the world And for that, replicating some information is useful.

 

[Alpha1]

It would be a very attractive function. I already run multiple related websites and need to interconnect the userbase.

 

[Reeve of Shinra]

1) Registration: How do we do registration?

Ideally it would be transparent to the end user. They would register like they would today only the information is stored in the site registration database, separate from the sites itself.

2) Updating a Profile: How does a user update a profile?

Same way, information is stored in the central registration system database and it can be cached locally for performance. Users would have the option of keeping the change local or spread to the master db.

3) How is information managed?

Many Sites -> Registration DB -> Many Sites

Private Message Alerts and User Alerts would be an rss type of syndication feed but this needs to be fleshed out further for private threads.

 

[tmb]

It may be too big of a solution but creating something like Aegir for Drupal would be amazing. Login to a master control panel that would allow you to manage users, sites, forums, etc all from one area. If you want to roll out a new site you simply add (or buy if you need) a license and hit add forum and fill in the info and it would install. Would really drive some sales I would think.

 

[ManagerJosh]

It may be too big of a solution but creating something like Aegir for Drupal would be amazing. Login to a master control panel that would allow you to manage users, sites, forums, etc all from one area. If you want to roll out a new site you simply add (or buy if you need) a license and hit add forum and fill in the info and it would install. Would really drive some sales I would think.

We're running into issues of syncing there.

 

[tmb]

We're running into issues of syncing there.

Of what? Users?

 

[ManagerJosh]

Of what? Users?

Data in general.

 

[Rigel Kentaurus]

Problems with sync'ing can be solved, in different ways, really, replication is a pretty much understood concept and it can be done in several ways. Be it partitioning, database replication, log replication ... the thing is, we want to keep the solution simple, as a lot of the target market for a product like XenForo isn't really big enterprise with many servers and staff resources. Were that the case, this software would have an additional zero at the end of the price tag.

What I would like to see is, first, a single sign-on, and that's it. Only share the login and password, the problem I would like to see solved is "let me login without registering again".

I am willing to give up other niceties that we could have, examples of that would be syncing the avatar, or using the same profile information (optionally), or having a single profile and profile messages, or even the alerts that was suggested before. Alerts is one that I would love to have, browse one site and have the alerts of the other site pop-up, that way I don't have to remember to open it ....

And some other non-replication issues like, if the site has different terms&conditions, well, the user has to accept them!

But all of that can wait. A good enough design can just map those thing to be done "in the future", and if we could just have only the single sign-on feature of it... that would solve some scenarios.