dRD
Member
Alright, just wanted to hear some thoughts and pointers to our plan. So, here goes:
We have an existing custom-built site that has about 1.2M registered members, member features used in ten different site sections, in different ways, etc. One big part of the entire site is our forums (which is custom built as well and has served us well since yr 2000). We're now planning a project where we'd start our upcoming new (empty) forums with xenForo (rather than with our existing forum software). Purchased licenses, started going through the code & structure of xF, etc.
Here's our plan:
1) We intend to keep two separate user databases in use. That of xenForo's and that of our existing one. Our existing user database is so deeply rooted to our site that changing it to use xF's user database on all of our site sections would cost in excess of $100'000 in terms of work time. Thus, the idea of having two separate user databases.
2) We plan to keep those two user databases in sync. This is most reliably done by using MySQL triggers on both databases, that would automatically sync the inserts & updates to other database (with specific set of conversion rules).
3) We don't care about user levels, etc in sync process, but simply want to keep password hashes, usernames and email addresses in sync.
4) We don't plan to build a single, unified login. I.e. people would have to login separately to xF and to rest of the site. This is done in order to simplify the development process and can (will?) be changed in future. Only thing we want is to keep the users' login & email data in sync, so that the same account can be used in both, with same credencials.
Catches:
1) Different password hash mechanism.
Development plan:
1) Build a login module to xenForo that can handle our existing password hashes, if user has been imported from our existing user database (specific entry to xf_user_authenticate.scheme_class and the xf_user_authenticate.data column to store the imported password hash in the format our existing site has it).
2) add triggers to our existing database that would
-> make required inserts to xF's database when new entry is added to our 'users' table.
-> make required updates to xF's database when something is changed in our 'users' table
3) add triggers to xF's database that would
-> add a new line to our 'users' table when new user is added to xF's user database
-> update info on our 'users' table when something is changed in any of the xF's relevant user tables
4) Add one column to xF's some user table that would contain password hash in "our format" instead of xF's own format.
5) Add a hook / hack / something to all xF's templates that allow user to create or change his/her password via xF. That hook would add/update also the "our" password hash field that we added in #4. This field could then be triggered back to our existing user database accordingly, while the user's xF's authentication scheme would change to be the xF's own default one (which happens when user updates his/her password via xF -- or creates an account via xF rather than via our own code).
...in essence, doesn't involve much code on xF from us, but the #4 & #5 give me goosebumps. How does xF behave when updated if one of the tables has an extra column. Can hooks added to also "non-visible" templates like the ones that "do something" to user's password (like add a new user or update existing user's password)?
All thoughts, suggestions & info would be much appreciated, TIA.
EDIT: Apparently I can't edit the thread title in order to fix typo there
We have an existing custom-built site that has about 1.2M registered members, member features used in ten different site sections, in different ways, etc. One big part of the entire site is our forums (which is custom built as well and has served us well since yr 2000). We're now planning a project where we'd start our upcoming new (empty) forums with xenForo (rather than with our existing forum software). Purchased licenses, started going through the code & structure of xF, etc.
Here's our plan:
1) We intend to keep two separate user databases in use. That of xenForo's and that of our existing one. Our existing user database is so deeply rooted to our site that changing it to use xF's user database on all of our site sections would cost in excess of $100'000 in terms of work time. Thus, the idea of having two separate user databases.
2) We plan to keep those two user databases in sync. This is most reliably done by using MySQL triggers on both databases, that would automatically sync the inserts & updates to other database (with specific set of conversion rules).
3) We don't care about user levels, etc in sync process, but simply want to keep password hashes, usernames and email addresses in sync.
4) We don't plan to build a single, unified login. I.e. people would have to login separately to xF and to rest of the site. This is done in order to simplify the development process and can (will?) be changed in future. Only thing we want is to keep the users' login & email data in sync, so that the same account can be used in both, with same credencials.
Catches:
1) Different password hash mechanism.
Development plan:
1) Build a login module to xenForo that can handle our existing password hashes, if user has been imported from our existing user database (specific entry to xf_user_authenticate.scheme_class and the xf_user_authenticate.data column to store the imported password hash in the format our existing site has it).
2) add triggers to our existing database that would
-> make required inserts to xF's database when new entry is added to our 'users' table.
-> make required updates to xF's database when something is changed in our 'users' table
3) add triggers to xF's database that would
-> add a new line to our 'users' table when new user is added to xF's user database
-> update info on our 'users' table when something is changed in any of the xF's relevant user tables
4) Add one column to xF's some user table that would contain password hash in "our format" instead of xF's own format.
5) Add a hook / hack / something to all xF's templates that allow user to create or change his/her password via xF. That hook would add/update also the "our" password hash field that we added in #4. This field could then be triggered back to our existing user database accordingly, while the user's xF's authentication scheme would change to be the xF's own default one (which happens when user updates his/her password via xF -- or creates an account via xF rather than via our own code).
...in essence, doesn't involve much code on xF from us, but the #4 & #5 give me goosebumps. How does xF behave when updated if one of the tables has an extra column. Can hooks added to also "non-visible" templates like the ones that "do something" to user's password (like add a new user or update existing user's password)?
All thoughts, suggestions & info would be much appreciated, TIA.
EDIT: Apparently I can't edit the thread title in order to fix typo there
