XF 2.1 How are we meant to integrate anything with XenForo?

[improbable_airtime]

I've been working on a project the past few months where I've wanted to integrate XenForo with an external app, a Laravel app to be specific. I'm not trying to do anything too complicated, just basically have it so that if a user is logged into the forum, then they can access the app. If they aren't logged into the forum and they try and access the app, it just redirects them to the forum login.

I thought this would be fairly easy to achieve with XenForo since in my experience most modern forum softwares already have plenty of integration features like; Same Sign-On, Single Sign-On, REST API's with JWT functionality, etc... Yet I was mistaken. After months of playing around with different ideas and different integrations, I've almost come to the conclusion that there isn't really an ideal way to get this sort of functionality with XF, which is really quite disappointing. Every approach you take, there is always some ridiculous compromise you have to take, and most of the time you are left scratching your head at why/how something is happening due to lack of detailed documentation on pretty much anything relating to XenForo.

So I'm hoping to get a response from one of the developers as to why this is such a hard thing to achieve? XenForo is a great piece of forum software but trying to do any sort of integration with it has been one of the hardest things I've ever had to do as a developer, and it really feels lacking in that department.

In regards to integration, after scowering likely hundreds of forum posts about this topic, some dating back almost as long as 8 years ago, it seems like almost nothing has changed really, and that's quite disappointing. The most "reliable" method I've seen people using (and what I'm currently using) is manually importing the XF.php file into your external app and basically booting the entire forum framework a second time inside your app. This isn't ideal and it causes you to have to deal with a lot of compromises that make your app completely reliant on the XF internals, as well as not being very flexible in terms of development. For example, when using this approach you are accepting the compromises of;

• Not being able to write any tests since XenForo's internal code breaks them in a number of places so you have to comment out a fair amount of stuff inside the actual XF code to get tests to run.
• Dealing with really weird session errors most of the time when authenticating.
• Having to deal with the overhead of basically booting/managing an entire forum framework inside your own project.
• Your Forum and App MUST be on the same filesystem.
• Having to do a fair amount of information duplication in databases, etc...
• Not being able to update XF ever basically unless you want to spend the time confirming every change and making sure none of your code broke.

So I'm hoping @Mike or @Chris D might be able to answer a question for me;

• What is the correct/recommended way of handling functionality like this between XF and a third-party app? Obviously I do not expect a perfect answer since every situation/project is different. But at least having some form of documentation explaining the general idea of how you guys would recommend developers achieve this given how popular of a question it appears to be, I think would not only save the developers time, but also you guys time as well as it will result in less threads of "How do I implement XF auth into my 3rd party app" that you need to respond to constantly on an individual basis.

Hopefully there is an easier way that I'm perhaps missing or that will be added in the next XF release since the whole XF.php method is really quite a terrible way to have to integrate XF into a third-party app.

 

[robdog]

So many follow up questions, but I'll do the best I can to try and help you here. Correct me if I am wrong, but it sounds like XenForo is the system of record when it comes to user management. This is good and should definitely help with this integration.

IF it were me, I would look at extending the XenForo log in the controller so when you get a successful login it will also create a session within your Laravel app. However, the big question, are these apps on the same parent domain? Because I am sure your Laravel app uses some sort of cookies for auth control. If they are on separate domains, it creates a problem with setting crossSo again, extend the login controller so it can create a session record inside your Laravel app AND set the Laravel auth cookie. You would want to extend the logout controller to remove the session in your Laravel app as well.

Not being able to write any tests since XenForo's internal code breaks them in a number of places so you have to comment out a fair amount of stuff inside the actual XF code to get tests to run.

Are you modifying the core XF code? If so, I would stop that and build an addon specific to what you are trying to do. Then you can write tests specific to your addon.

Dealing with really weird session errors most of the time when authenticating.

This is going to happen when you are trying to control 2 different session system between 2 completely different apps. Ideally, whatever is in your Laravel app could be fully built within the XenForo code system to prevent this. Obviously, that could be a lot of work, so the other option is the overhead of maintaining the 2 session systems to talk with each other.

Having to deal with the overhead of basically booting/managing an entire forum framework inside your own project.

You don't have to mash the file systems together. Subdomains can point to different file systems/structures and still work together.

Your Forum and App MUST be on the same filesystem.

Technically not true. The only thing both apps need is the ability to read/write to the each other's database AND the ability to manage cookies for each other's app.

Having to do a fair amount of information duplication in databases, etc...

You would have to expand on this a little more.

Not being able to update XF ever basically unless you want to spend the time confirming every change and making sure none of your code broke.

Again, do NOT modify the core XF code. Always, always, always create an addon. The devs here are great and keep the core code up to date and will inform developers about massive breaking changes in new versions that devs should watch out for with their addons.

Side note, XenForo is much much more than forum software. It's basically a platform in and of itself. I have basically built an entire application with it that doesn't even use the forum feature. (yet) Finally, I can probably answer questions here and there for you, but you will need a decent amount of coding experience to get this to work. Good luck with your project...

 

[improbable_airtime]

So many follow up questions, but I'll do the best I can to try and help you here. Correct me if I am wrong, but it sounds like XenForo is the system of record when it comes to user management. This is good and should definitely help with this integration.

IF it were me, I would look at extending the XenForo log in the controller so when you get a successful login it will also create a session within your Laravel app. However, the big question, are these apps on the same parent domain? Because I am sure your Laravel app uses some sort of cookies for auth control. If they are on separate domains, it creates a problem with setting crossSo again, extend the login controller so it can create a session record inside your Laravel app AND set the Laravel auth cookie. You would want to extend the logout controller to remove the session in your Laravel app as well.



Are you modifying the core XF code? If so, I would stop that and build an addon specific to what you are trying to do. Then you can write tests specific to your addon.



This is going to happen when you are trying to control 2 different session system between 2 completely different apps. Ideally, whatever is in your Laravel app could be fully built within the XenForo code system to prevent this. Obviously, that could be a lot of work, so the other option is the overhead of maintaining the 2 session systems to talk with each other.



You don't have to mash the file systems together. Subdomains can point to different file systems/structures and still work together.



Technically not true. The only thing both apps need is the ability to read/write to the each other's database AND the ability to manage cookies for each other's app.



You would have to expand on this a little more.



Again, do NOT modify the core XF code. Always, always, always create an addon. The devs here are great and keep the core code up to date and will inform developers about massive breaking changes in new versions that devs should watch out for with their addons.

Side note, XenForo is much much more than forum software. It's basically a platform in and of itself. I have basically built an entire application with it that doesn't even use the forum feature. (yet) Finally, I can probably answer questions here and there for you, but you will need a decent amount of coding experience to get this to work. Good luck with your project...

Hey @robdog ,

Thanks for the detailed reply. My current way of doing it has been to use something similar to this (https://github.com/swede2k/xf2bridge) but I wrote most of it myself, only found this one AFTER I'd already made my own.

Also quickly to clarify my app and the forum will be on the same domain, so there should be no issues with session/cookie sharing.

Anyway as you can see, it includes the XF.php file so that we can have access to XenForo internally. This works, but it feels really clunky and like there should be a better solution. Let me explain the points I made previously so it's a bit easier to understand.

• "Not being able to write any tests since XenForo's internal code breaks them in a number of places so you have to comment out a fair amount of stuff inside the actual XF code to get tests to run."
  • So with this, using the method above I've found that if you try and run any tests, you will get some weird ob level errors and the only way to stop them is to completely comment out certain sections of code. Once you've commented those sections out, it works great, but it really feels like an unecessary step and as you said in your own response I definitely should not be modifying the XF src code. I completely agree with you and I would love to not edit the XF src code, but it doesn't work unless I do it so I feel almost like I'm forced to remove it unless I just don't want to use tests, which I do.
  • Also regarding tests, it's really a massive pain in the ass to even write tests when using this method, becuase you essentially have to mock an entire user and can't leverage things like Factories to generate new users that meet certain criteria when writing your tests. This has been by far one of the worst parts about all of this, since I simply can't "whip up a user with admin permissions and then remove it after the test is done" when integrating with XenForo.
• "Dealing with really weird session errors most of the time when authenticating."
  • So if you require the XF.php and use a function like getVisitor(), then that handles all the session stuff for you, but again it just feels a bit clunky and like there should be a much easier way to do this. It also occasionally runs into errors where it will just fail because the session expired or something else, and it requires a full redirect back to the forums and then back to the Laravel app again. It's quite a pain from a UX perspective since this would undoubtable confuse users if they click a link to go to the app and it just randomly redirects them back to the forum.
• "Your Forum and App MUST be on the same filesystem."
  • What I meant by this is they have to be on the same filesystem with the "common" method because you need to source the XF.php file and require it. Doing this over multiple servers is going to be more hassle than it's worth.
• "Having to do a fair amount of information duplication in databases, etc..."
  • Users is a prime example of this. Ideally speaking, I'd love to just extend the XF users from the XF table and reference foreign keys from my app to xf_users table inside the XF database, but since I need to add columns etc... I basically need to make my own users table on my Laravel app and keep the data in sync between them. It's incredibly annoying and frustrating and way too much overhead than I would like.
• "Not being able to update XF ever basically unless you want to spend the time confirming every change and making sure none of your code broke."
  • What I meant by this is if you are already requiring the XF.php file and then you update XF, you are probably going to need to reference this file again and make sure yourself that nothing internal changed, since if you are leveraging anything internal via XF and it randomly gets removed or gets changed, then obviously your app's code wont behave correctly.

Hopefully that gives some context in what I'm talking about.

 

[robdog]

You do make an interesting point about unit testing. I do with that the XenForo dev team would release a starter pack of what they use for unit testing and mocking data. This would definitely help those who are building add-ons. I know I would go through them a bit and see how I could modify my current unit testing environment.

 

[svpernova09]

@ improbable_airtime​

Did you ever figure out a solution? I managed to fork XFBridge and get it working for Laravel 6, but looks like the guards aren't working for 8. I figured I'd do one last google search before diving into making my own bridge/guard compatible w/ newer Laravel.

 

[Sim]

Not being able to write any tests since XenForo's internal code breaks them in a number of places so you have to comment out a fair amount of stuff inside the actual XF code to get tests to run.

You do make an interesting point about unit testing. I do with that the XenForo dev team would release a starter pack of what they use for unit testing and mocking data. This would definitely help those who are building add-ons. I know I would go through them a bit and see how I could modify my current unit testing environment.

FYI - I created a unit testing framework library and wrote a tutorial on unit testing XenForo addons:

Unit testing XenForo addons - tutorial

Compatibilty For XenForo v2.1 addons, you should use Unit Test Framework v1.x For XenForo v2.2 addons, you should use Unit Test Framework v2.x For XenForo v2.3 addons, you should use Unit Test Framework v3.x Upgrading Unit Test Framework...

xenforo.com

It doesn't solve all of the problems (testing the database is still particularly problematic since we can't easily swap out the database for something like an SQLite in-memory database) - but it will get you a long way towards effective unit testing.

I use this library for testing many of my own addons and I do a lot of integration work too (more back-end stuff rather than user level SSO integration etc).

My unit testing library was inspired by the unit testing framework used by Laravel.