Not planned Prevent direct add-on access to the database

[psTubble27]

Add-ons create sql tables they need for their usage. When they are uninstalled however, there can remain orphan sql tables.

Instead all database access should filter through the XF engine. The addon would invoke a function like xen_create_table("tablename"). This would allow XF to keep track of all add-on created tables, and when uninstalled, to clean up those tables automatically.

In the ideal world, uninstalling 100 add-ons would leave the database in the same pristine state as if they were never installed.

The primary benefit of this feature is that if the add-on is unneeded, or presents a security risk, its data can be gotten rid of without technical hassle.

 

[Jeremy]

If an add-on doesn't uninstall tables and or removed added columns, you should report it to the developer. It's up to the add-on author to properly install / uninstall their add-on. And nothing XenForo does can prevent the situation you describe, if an add-on wants to access the database, XenForo can't prevent that or force them to use their classes.

 

[Paul B]

Agree with KK on all points.

 

[JulianD]

However, the idea of an install/uninstall framework for addons is not bad at all.

 

[tyteen4a03]

However, the idea of an install/uninstall framework for addons is not bad at all.

The system will need to help devs make upgrading easier.

OT: It's not XenForo's problem an addon developer is not cleaning up their own mess.

 

[Jeremy]

However, the idea of an install/uninstall framework for addons is not bad at all.

The benefits it will give developers is minimal.

 

[psTubble27]

If an add-on doesn't uninstall tables and or removed added columns, you should report it to the developer. It's up to the add-on author to properly install / uninstall their add-on. And nothing XenForo does can prevent the situation you describe, if an add-on wants to access the database, XenForo can't prevent that or force them to use their classes.

In broad terms this is a Xenforo ecosystem. We rely on XF to keep things in order, if the add-on developer is incompetent and/or malicious. If there is a virus in a Windows environment nobody says "hold the virus author accountable, why do you blame Microsoft". No we involve Microsoft as well, because it's their ecosystem.

Now it's another thing entirely, if XF just physically cannot prevent add-ons from accessing the database, but the utility of the principle in the abstract can't be denied.

 

[Jeremy]

Comparing Microsoft to XenForo is like comparing Earth to a house. When on Microsoft, I would have to use functionality exposed to me for it to work. If I really wanted to, I could write my add-on without using XenForo's database classes at all, because all of the direct PHP functions are available.

As I said a few minutes ago, the actual benefit it gives developers will be extremely small, if any at all. The queries that are used to create a table are slightly more complex than "Create Table X".

Also, having data in the database can't really pose a security risk after an add-on is uninstalled.

 

[Marcus]

The code of xenForo is based on the framework from ZEND. Some frameworks work like psTubble27 suggested. ZEND does not work like this, here you access the database directly with SQL queries. Bottom line: As long as ZEND does not include this (which it most likely does not), this suggestion can't be (or it is too much hassle to do so) implemented.

 

[tyteen4a03]

The code of xenForo is based on the framework from ZEND. Some frameworks work like psTubble27 suggested. ZEND does not work like this, here you access the database directly with SQL queries. Bottom line: As long as ZEND does not include this (which it most likely does not), this suggestion can't be (or it is too much hassle to do so) implemented.

The term you're looking for is Object Relations Manager (ORM).

And no, there isn't an ORM in either ZF1 or 2. However, XF can implement anything they need without relying on Zend - XenForo is not a strict ZF-based app.

 

[psTubble27]

As I said a few minutes ago, the actual benefit it gives developers will be extremely small, if any at all. The queries that are used to create a table are slightly more complex than "Create Table X".

I think you are missing the point of this suggestion. The point here is not to provide a benefit to developers but to provide a benefit to consumers, which may make things more difficult for developers than anything else.

Comparing Microsoft to XenForo is like comparing Earth to a house. When on Microsoft, I would have to use functionality exposed to me for it to work. If I really wanted to, I could write my add-on without using XenForo's database classes at all, because all of the direct PHP functions are available.

Isn't that just up to XenForo's architecture? It isn't possible for an add-on to run without it running within XF. If XF architecture will prohibit the addons from having this access, you wouldn't be able to.

Also, having data in the database can't really pose a security risk after an add-on is uninstalled.

It may if there's data in your own database you didn't want to store and which some other add-on later can retrieve. Also it is a matter of space and efficiency. I don't see why you are trying to shoot this down so hard.

 

[Mike]

I think you are missing the point of this suggestion. The point here is not to provide a benefit to developers but to provide a benefit to consumers, which may make things more difficult for developers than anything else.

I'm getting confused as I feel like you're proposing from two different things and I don't know what you're actually suggesting.

The initial suggestion is roughly something that only benefits developers directly, in that it automatically cleans up data for them. Obviously they should be cleaning up their data on uninstallation and this could make it happen automatically, but there's nothing to stop them from doing it now. It just prevents them from having to write the code explicitly. (Conversely, there are things they may still need to clean up manually anyway.)

But then this seems to have taken a turn into sandboxing to provide security by limiting add-on access to APIs. Let's just say this is simply not possible. Comparisons to operating systems (or even any binary-based executable) are really of no use because they're simply not relevant to this situation.

 

[Jeremy]

I think you are missing the point of this suggestion. The point here is not to provide a benefit to developers but to provide a benefit to consumers, which may make things more difficult for developers than anything else.



Isn't that just up to XenForo's architecture? It isn't possible for an add-on to run without it running within XF. If XF architecture will prohibit the addons from having this access, you wouldn't be able to.



It may if there's data in your own database you didn't want to store and which some other add-on later can retrieve. Also it is a matter of space and efficiency. I don't see why you are trying to shoot this down so hard.

As Mike said, it seems you've switched the reason for this like Mike said. But either way, my comment still stands. There is nothing stopping me from writing my own SQL queries and interacting with the database directly. And data doesn't pose a security threat, but it now seems to me that you are more worried about limiting access to such data for other add-ons (impossible) or worried about space, which your suggestion can't really achieve.

As Mike has said, just table creations aren't necessarily all the clean up that needs to happen and there is no way XenForo can provide sandboxed APIs for every single possible method of storing something (uploads, tables, columns, etc.), so its more or less up to the developer to properly clean up anyways.

 

[psTubble27]

I'm getting confused as I feel like you're proposing from two different things and I don't know what you're actually suggesting.

The initial suggestion is roughly something that only benefits developers directly, in that it automatically cleans up data for them. Obviously they should be cleaning up their data on uninstallation and this could make it happen automatically, but there's nothing to stop them from doing it now. It just prevents them from having to write the code explicitly. (Conversely, there are things they may still need to clean up manually anyway.)

But then this seems to have taken a turn into sandboxing to provide security by limiting add-on access to APIs. Let's just say this is simply not possible. Comparisons to operating systems (or even any binary-based executable) are really of no use because they're simply not relevant to this situation.

Sorry, I see how what I said could could've been unclear. I did mention the developer-friendly database function, but the point of having it was, so as to funnel all DB access through XF, preventing add-ons from having direct access. Hence the title of the thread.

I am proposing a system that will give developers less access to the system. If we funnel everything through XF core (and give it a friendly face so that the devs won't grumble), then XF can keep tabs on everything add-ons do. If the add-on uninstalls, we can clean up all the mess after it.

The system could be applied in very powerful ways in future years. For example it could monitor add-on activities and even prevent malicious behavior from taking effect. Something robust like that, protecting users, has not been seen in forums to date which makes it a perfect target for XF innovation.

 

[Jeremy]

You want sandboxing. This is impossible with a web application. No matter how 'friendly' the XenForo functions are, anybody could write a script that includes the XenForo configuration, get the database details, and connect directly to the database.

 

[psTubble27]

I look at the countless add-ons that are now sprouting up in the Resources section, and I can't help but think that they are NOT viable for a quick download and experiment. Forum and DB integrity have paramount importance to a careful administrator, and add-ons having unlimited rights means that he has to trust the add-on authors with the life of his forum, or even better, be expert in PHP and go through their source code himself. Most people won't be. Anything less than this knowledge will mean that the security concerns override the download-and-experiment impulse, among a large chunk of the XF userbase. Only the incompetent admin will experiment with ALL add-ons, and the virtuoso PHP admin will just code everything himself (like digitalpoint did).

If add-ons were in a sandbox (perhaps in just one aspect for now, such as DB access, and expand in their control in future releases), this would lead to a lot more downloading and experimentation with add-ons, without fear that they would sully the database with garbage tables, and at worst corrupt the system through incompetence.

No matter how 'friendly' the XenForo functions are, anybody could write a script that includes the XenForo configuration, get the database details, and connect directly to the database.

You are assuming a security breach. How would a regular person get the configuration/DB details without hacking?

 

[Mike]

You are assuming a security breach. How would a regular person get the configuration/DB details without hacking?

There is always a database object that can access things. Anything that XF can read can be read by an add-on.

What you are asking for is simply not possible (from a security standpoint).

 

[psTubble27]

Ahh I see. Thanks for responding Mike.

I come from a desktop dev. environment and especially the Java sandbox model. Could somebody explain in specifics why it isn't possible? If I just approach it analytically, the XF php file (say, index.php) is always loaded first when you enter the XF system at any point, so theoretically the XF core should always be in control if it wanted to...

Also, if this database object can be read by any add-on, am I correct in assuming that it is one huge security breach waiting to happen (again, coming from the JVM and the PC protected memory world)? Can an add-on basically retrieve all database config settings for your site? I understand that it's not a XF-specific issue. Just trying to get a handle on how far this problem extends.

 

[Jeremy]

No, any add-on can include the XF configuration and access the DB. As Mike said, this is impossible from a technical stand point. Sandboxing would need implemented in PHP.

PHP has access to the DB natively.

 

[Biker]

I come from a desktop dev. environment and especially the Java sandbox model.

Of course, we all know how secure that model is. Hasn't been a java exploit in years. Oh. Wait.....