Ozzy47
Well-known member
Such as what addon(s)?
Resource standards guidelines published
- Thread starter Chris D
- Start date
Such as what addon(s)?
Alpha1
Well-known member
A quick search bring this post up: https://xenforo.com/community/threads/bbcode-parser-all-deleted.151163/post-1279942
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.
jmurrayhead
Well-known member
Not a bad idea.
Ozzy47
Well-known member
Also I would expand on that and any time a resource is removed because of housekeeping that the prefix be “Deleted Housekeeping”
Ozzy47
Well-known member
Robust
Well-known member
Few questions. @Chris D
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:
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?
What if the extension does something that doesn't care of the return type of the parent 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.
----
One query re. resource guidelines also:
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:
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.
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).
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:
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?
What if the extension does something that doesn't care of the return type of the parent 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.
----
One query re. resource guidelines also:
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:
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:
Snog
Well-known member
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.
Robust
Well-known member
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.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.
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.
Yeah for the most part.
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.
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.
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.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.
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.
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.
Robust
Well-known member
@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).
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.?
"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.?
What about code that is minified, and/or variables renamed from things like $forum to $k, $threadCreator -> $kA, etc. -- is this allowed?
Last edited:
Should be ok.
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.
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?
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.
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.
Ozzy47
Well-known member
From, Review resources before approving them (XF Community)
Have there been any advances in this area? I think it’s the future, but I could be wrong.
Have there been any advances in this area? I think it’s the future, but I could be wrong.
Similar threads
