Resource standards guidelines published

Hm.. an addon gets removed here on Xenforo if you don't meet the requirements, but you still allow advertisement for such addons to be posted here. Isn't that kinda nullifying the effect of removing the addon?

Such as what addon(s)?
 
Only ones I see are from AndyB and those were removed because of the title. So those should not be banned from being discussed or promoted on here.
 
Ultimately 99% of addons end up being looked at through the RM, I think I know the resource youre on about, and to be honest a thread with the last 2 pages being complaints, probably wont cause anyone any issues. If anything it would be a benefit to warn people off.
 
Few questions. @Chris D

I should probably note that the language used throughout the guidelines is significant.

There’s a difference when we say “should” and “must”.
As I understand, 'should' is used where something is a best practice / generally applicable in most cases, but not adhering to it would not cause 'issues' (and there may be legitimate reasons to not do it).

21. Add-ons must utilise the various “handler” systems where available to their full extent rather than extending classes to inject custom behaviour. Including, but not limited to, Spam checking which must be implemented using the spam checker handler system rather than extending the checkForSpam methods in different places.

Should this be a 'must'? e.g. you may wish to only have spam checking in a particular area, or you may just be doing bad practice and extending the various methods, but this isn't necessarily a security risk or similar? This bullet doesn't really seem to fit to the pattern of should/must used elsewhere throughout the guidelines.

----

Some queries on other 'must' guidelines:

22. If a class extension is required to extend core methods then it must be extended properly, rather than overridden, by calling the parent method.

If there is some particular reason to override the method (i.e. you wish to replace functionality, or disable it, e.g. disable a certain controller action, and this is an intended purpose of your add-on) is this not allowed?

23. If a core method has different return types with different behaviours (e.g. controller actions return different types of reply objects) then the extended code must check to ensure it’s working with the correct type.

What if the extension does something that doesn't care of the return type of the parent method?

27. If an add-on needs to make HTTP requests, it must use the XF HTTP client rather than making cURL requests manually.

I've never had a reason to not use the XF HTTP client in my usages, but should this be a 'must'? Especially since point 14 allows for the usage of direct access of superglobals with data if the data is appropriately filtered. It does seem excessively restrictive to not allow usage of cURL directly.

----

One query re. resource guidelines also:

Executable code (such as PHP or SQL) cannot be downloaded by your add-on unless explicitly requested by the user, as a core function of your add-on. For the avoidance of doubt, your installation or uninstallation routines must not download code to execute.

This sounds like it also includes add-ons which support auto updating functionality (or check for updates, and allow the admin to do one-click updates), as updating isn't really "the core function" of an add-on (unless, I guess, it's an updating add-on). Since the XF core allows updating functionality in a similar manner now, and there's add-ons which are made to allow for similar upgrading functionality, I would presume this is an acceptable use case of downloading executable code.

----

And for clarification:

Code must not be encrypted, encoded or otherwise obfuscated.

I presume this means add-ons are not allowed to perform any kind of obfuscation, or protection of their source code, (which would include the renaming of variables) or any kind of deviation between the release code and the source code? Are add-ons allowed to do any kind of protection of their source code against things like piracy, and if so, what things are allowed?

And finally, perhaps the resource guidelines (at least the add-on portion of it) and standards should be combined? I don't see why the add-ons part of the resource guidelines is separate to the standards.
 
Last edited:
Executable code (such as PHP or SQL) cannot be downloaded by your add-on unless explicitly requested by the user, as a core function of your add-on. For the avoidance of doubt, your installation or uninstallation routines must not download code to execute.
I'm going to answer this part because when I saw it, I felt it was directed right at me because of part of my protection scheme at the time the standards were created. ;)

I use to download php code during each step of installation from my servers and execute it during the install process.

THAT is not allowed. :)

That's MUCH different than downloading the zip file and installing it. Which is generally what the update programs do.
 
I'm going to answer this part because when I saw it, I felt it was directed right at me because of part of my protection scheme at the time the standards were created. ;)

I use to download php code during each step of installation from my servers and execute it during the install process.

THAT is not allowed. :)
I'm not familiar with anything you did, and none of my comments were directed at anyone. All of those questions are just to clarify the guidelines as they're stated literally.

With that particular one, my concern is just that (in the way it's worded) it also disallows add-ons that allow one click upgrades or automatic upgrades (especially useful for x.x.X level releases, where forum admins might be too lazy to upgrade but happy for bug fixes/security updates to be applied automatically). These use cases are, in effect, executing downloaded code (and could be downloading malicious code, as well). Since XenForo itself now does it, and there's also a ThemeHouse add-on for it, I presume some cases of this are allowed. It would be helpful if the point was clarified and probably reworded to account for the scenarios where XenForo will and will not allow it.
 
I didn't think YOU were directing it at me. Just the way I felt when the standard was created. :D

I also understand what you meant. But I wanted to give and example of what is not allowed. ;)
 
As I understand, 'should' is used where something is a best practice / generally applicable in most cases, but not adhering to it would not cause 'issues' (and there may be legitimate reasons to not do it).
Yeah for the most part.

Should this be a 'must'? e.g. you may wish to only have spam checking in a particular area, or you may just be doing bad practice and extending the various methods, but this isn't necessarily a security risk or similar? This bullet doesn't really seem to fit to the pattern of should/must used elsewhere throughout the guidelines.
The specific thing we had in mind for this was to prevent someone from wanting to implement a new anti-spam content checking service, and then doing so in some random specific service somewhere (like the post creator service) because there's no reason that anti-spam content checking service couldn't be used to prevent profile post spam, contact form spam, media gallery comment spam, etc. Adding it to the proper spam checking system means that all content types, even those from other add-ons, will make use of it automatically.

From our view, limiting spam checks to only specific areas is invalid. Spam checks should work regardless of content type being checked.

If there is some particular reason to override the method (i.e. you wish to replace functionality, or disable it, e.g. disable a certain controller action, and this is an intended purpose of your add-on) is this not allowed?
There are very few reasons to totally override a method. This is targeting specifically the common case we see which is copy and pasting the existing method and adding/removing lines, not calling the parent class, and overall just breaking any form of inheritance.

What if the extension does something that doesn't care of the return type of the parent method?
The significant case dor this one is something like extending a controller action which may be able to return different reply objects. For example, setParams() is a method that only exists on the View reply so you must check the controller action has returned a View reply before accessing that method.

I've never had a reason to not use the XF HTTP client in my usages, but should this be a 'must'? Especially since point 14 allows for the usage of direct access of superglobals with data if the data is appropriately filtered. It does seem excessively restrictive to not allow usage of cURL directly.
Is there a reason to use cURL directly when there's a fully featured HTTP client available? Yes, it is a must to use it.

This sounds like it also includes add-ons which support auto updating functionality (or check for updates, and allow the admin to do one-click updates), as updating isn't really "the core function" of an add-on (unless, I guess, it's an updating add-on). Since the XF core allows updating functionality in a similar manner now, and there's add-ons which are made to allow for similar upgrading functionality, I would presume this is an acceptable use case of downloading executable code.
It was actually specifically targeting the situation we had with a certain developer we don't talk about here anymore. They were downloading absolutely unknown and unauditable code and executing that on customer forums.

I presume this means add-ons are not allowed to perform any kind of obfuscation, or protection of their source code, (which would include the renaming of variables) or any kind of deviation between the release code and the source code? Are add-ons allowed to do any kind of protection of their source code against things like piracy, and if so, what things are allowed?
This is about the auditability and legibility of the source code. Code that is encrypted with IONcube or obfuscated with base64 encoding or similar isn't allowed.
 
@Chris D So some the use cases I specified for each one would still be allowed? (e.g. you can override a controller method if it is the intention of the add-on to disable that controller method).

It was actually specifically targeting the situation we had with a certain developer we don't talk about here anymore. They were downloading absolutely unknown and unauditable code and executing that on customer forums.
"Unknown and unauditable" from the developer's own endpoint or from endpoints they didn't control?

Assuming this means developers are allowed to download code from their own endpoint (for purposes like to upgrade an add-on), what happens in cases where the developer's endpoints are compromised and malicious code is instead downloaded, etc.?

This is about the auditability and legibility of the source code. Code that is encrypted with IONcube or obfuscated with base64 encoding or similar isn't allowed.
What about code that is minified, and/or variables renamed from things like $forum to $k, $threadCreator -> $kA, etc. -- is this allowed?
 
Last edited:
@Chris D So regarding all those points, other than the HTTP client, the use cases I specified for each one would still be allowed? (e.g. you can override a controller method if it is the intention of the add-on to disable that controller method).
Should be ok.

"Unknown and unauditable" from the developer's own endpoint or from endpoints they didn't control?

Assuming this means developers are allowed to download code from their own endpoint (for purposes like to upgrade an add-on), what happens in cases where the developer's endpoints are compromised and malicious code is instead downloaded, etc.?
If you're talking about a self-update type system, that would be allowed. For a self-update system you're mostly just replacing one version of the code with another version of that same code so that's not really "unknown or unauditable".

The issue that spawned this situation was malicious add-ons downloading unknown code and for unknown reasons. The idea of code being auditable is that if a customer wanted to have your code reviewed (or indeed if we ever did code reviews) that they would be able to understand exactly what all of the code is doing, and the end effect of that code being executed.

What about code that is minified, and/or variables renamed from things like $forum to $k, $threadCreator -> $kA, etc. -- is this allowed?
Minified code or renaming variables is fine. Of course minification has a net benefit in some cases, especially for JavaScript. Ideally the unminified code should still be available though (we'll call that a should, rather than a must though -- sometimes you might be including a library for which there isn't an unminified version, for example).

Renaming variables as per your example though seems very arbitrary and unnecessary so I'd probably want to understand the motivations behind that a little more. If there's no benefit to it, why bother?
 
What about code that is minified, and/or variables renamed from things like $forum to $k, $threadCreator -> $kA, etc. -- is this allowed?
I honestly can't think of any reason why renaming variables in such a way would be necessary and/or make sense, apart from trying to make it harder to understand what is going on - which IMHO is exactly what the guidelines forbid.
 
Last edited:
Exactly my point though reading it back it's a little confused.

Where there is a reason to, such as for the sake of performance, minifying JS (which obviously includes renaming variables) is acceptable. There's little reason to do that in server-side code, however, unless it's for the explicit purpose, as Kirby implies, of obfuscating the code. That use case, wouldn't be compatible with the standard on the grounds of obfuscation.
 
Back
Top Bottom