Resource standards guidelines published

[Chris D]

Today we are publishing our guidelines for Resource standards which aims to ensure that all developers who are releasing add-ons for XenForo are aware of the minimum quality and standards expected by us.

Although we do not currently perform code reviews on any resources, we will reserve the right to do that if we have reason to believe that any resources are falling short of the minimum standards.

However, if we discover resources which are found to be not adhering to these standards then the resources will be removed until such improvements have been made. In extreme cases, we may prevent the authors from releasing resources here entirely.

Although the potential actions mentioned above may seem extreme, it is important that we foster a commitment to quality for the safety, privacy and security of our customers, their users and their data.

 

[Jake B.]

Looks like quite the list! Couple things that could make sense:

• Increase execute_order if you're removing something from a template in template modifications that someone is likely to target to add something before/after
• Don't remove core variables that are reasonably expected to always be available in a controller's parameters (such as nuking $thread on XenForo_ControllerPublic_Thread::actionIndex
• Don't leave orphaned data when deleting a parent

 

[TickTackk]

Where a specific code event exists, a listener should be created to utilise it rather than a full class extension.

Does this apply to entity_structure, entity_post_save, entity_post_delete and other events like those?

 

[Jake B.]

Does this apply to entity_structure, entity_post_save, entity_post_delete and other events like those?

XFRM/MG doesn't use these, and IMO it seems cleaner to extend the Entity for that, so I hope not

 

[TickTackk]

I avoid using entity_structure only because I can just make use of class extensions and add property comments which helps a lot when writing stuff. So yea I hope it's fine as well.

 

[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”.

We acknowledge that, for entities especially, class extensions can be more appropriate especially as you’d likely be needing to add new methods in there as well as changing the structure.

 

[Snog]

I assume if there's something that needs to be changed, such as using cURL directly, that it's acceptable to be changed in the next add-on version release.

 

[Chris D]

Yes that’s reasonable.

Most of these things aren’t life or death. Though some of them are, of course

 

[Ozzy47]

Although there have been a couple of casualties due to the guidlines, I am glad to see that the guidelines are being enforced and reasonable time is given to the developers to make the necessary changes to their addons.

 

[woei]

As an end user I can only be really happy about this. Will users be notified when a resource that they have downloaded is removed?

 

[Ozzy47]

If you are watching the resource sure.

 

[S Thomas]

Is the resource name shown anywhere without the tag line on the desktop version?
If not, I'd suggest to change the naming rule to "title + tag line". I mean what the rules right now are trying to enforce is a tag line excerpt in the title. Afaik there is no listing without tag line, so you would have 2 tag lines..

 

[alexD]

Code must not be encrypted, encoded or otherwise obfuscated.

What if obfuscated code is a core requirement?

Take for example the following:


Each download/installation of this add-on would include at least 64 unique JavaScript files, dynamically generated from template files.
The templates (from which those 64 files would derive from) would vary by having different ad block detection algorithms (element class names or ad network baits, which I don't want to be easily readable or predictable).
The generated .js files would then be obfuscated (using a library such as this) and rotated in a lax manner based on the visitor's session id and/or server time.

The above description is probably already complicated. To possibly make things even more, each of those .js files would include a set number of URL paths stored in strings, which would point to custom routes. The related controllers would then be responsible for negotiating/revealing the BbCode contents.

The development is still in early/exploratory stage (started before the guidelines were published and paused thereafter), but I wonder if such a resource would be allowed.

 

[S Thomas]

If you provide the template files aswell to the customer and the obfuscated .js files get generated on their side, there shouldn't be any conflicts with the resource guidelines I think.

 

[alexD]

I wouldn't mind including the original templates in the add-on package, but expecting prospect users (board admins) to get a Node.js stack available just to generate obfuscated .js files is utterly unrealistic.

Using an API service, such as Jscrambler wouldn't be financially viable.
Rolling my own solution where I provide a custom javascript-obfuscator API brings us back to code injection trust issues. Even if that would be acceptable, it'd be too much trouble.

I might have to simplify the add-on so it doesn't require such aggressive obfuscation.

 

[Jake B.]

I wouldn't mind including the original templates in the add-on package, but expecting prospect users (board admins) to get a Node.js stack available just to generate obfuscated .js files is utterly unrealistic.

Using an API service, such as Jscrambler wouldn't be financially viable.
Rolling my own solution where I provide a custom javascript-obfuscator API brings us back to code injection trust issues. Even if that would be acceptable, it'd be too much trouble.

I might have to simplify the add-on so it doesn't require such aggressive obfuscation.

I'd imagine as long as the source is available along with the obfuscated version, and it was made clear that the JS served to the client was obfuscated (along with the reasons) it'd be fine as if someone really didn't trust your obfuscated version they could create their own, especially since it's required functionality for the product. But I'm sure @Chris D could provide more information

 

[Snog]

The only way I think it would be allowed is if the obfuscated code on the displayed page was generated on the fly from in the clear templates. Otherwise, any pre-generated obfuscated js could contain literally anything without the user knowing what's in there. And expecting the user to generate their own is unreasonable in most cases.

And besides that, obfuscated js could start setting off malware warnings in a lot of cases.

 

[Chris D]

I'd imagine as long as the source is available along with the obfuscated version, and it was made clear that the JS served to the client was obfuscated (along with the reasons) it'd be fine as if someone really didn't trust your obfuscated version they could create their own, especially since it's required functionality for the product. But I'm sure @Chris D could provide more information

This does seem reasonable to me. If it is possible to include the non-obfuscated code, giving people the option not to use your own, and it is all explained in the resource description then there's not a lot to argue about.

 

[S Thomas]

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?

 

[DragonByte Tech]

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?

That sounds properly ominous, can you clarify?


Fillip