Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2009-07-09 16:33:16

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,721
Website

Plugin filtering for admin list pages

I wonder if this, currently rather dangerous patch, is too hackish a concept to be considered? It’s 1 extra line in txp_list.php to allow additional clauses in the criteria.

This hook allows plugin authors to more easily show only the current author’s articles, or hide articles in certain sections, etc. For reference, my first attempt was using pluggable_ui(), which seemed a lot cleaner to me. The drawback was that simply omitting list items screws up the pagination :-(

Anyway, is this idea stupid or does it have a valid application? It could of course be extended to Image, File and Link pages if deemed useful. Or is there a better way to do this, besides allowing raw SQL to be added to the clause, which I must admit makes me slightly nervous.

Thoughts?

Last edited by Bloke (2012-07-17 23:42:06)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#2 2009-07-09 17:00:55

net-carver
Archived Plugin Author
Registered: 2006-03-08
Posts: 1,648

Re: Plugin filtering for admin list pages

How now StefBloke?

Is this idea stupid or does it have an application alongside the power of per-author and per-priv enhancements in 4.2.0? <snip> Or is there a better way to do this, besides allowing raw SQL to be added to the clause, which I must admit makes me slightly nervous.

I can think of at least one place in the MLP pack where this would come in handy.

Perhaps the hook should not allow totally raw SQL, but do some kind of sanity check on the returned values. For example, it could truncate at the first ' OR' in the returned value and only allow the addition of ‘ANDs’ to a WHERE clause. So the hook returns a string like `author` <> 'stef' and this gets tacked on as WHERE blahblah AND (`author` <> 'stef'). Should a rogue string like `author` = 'stef' OR 1=1 be returned, the truncation would kick in.

Probably need to cover other cases as well; this is just off the top of my head to kick things off.


Steve

Offline

#3 2009-07-09 17:37:06

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,721
Website

Re: Plugin filtering for admin list pages

net-carver wrote:

Perhaps the hook should not allow totally raw SQL, but do some kind of sanity check on the returned values [snip]

Works for me. The forced ‘AND’ is a good idea (might make the patch an extra line to detect if the callback has been used). I can certainly think of a situation where chaining a few clauses might be useful, for example, AuthorID = 'stef' AND Section NOT IN ('omitme1', 'omitme2'). Struggling to find an OR case, so your logic appears sound, but there’s probably a legitimate use of OR out there. Somewhere?

One thing I didn’t consider is how the thing behaves if two plugins try to employ the hook. I think it still works. Ummm, I think.

Last edited by Bloke (2009-07-09 17:40:51)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#4 2009-07-09 22:05:20

hakjoon
Moderator
From: Arlington, VA
Registered: 2004-07-29
Posts: 1,634
Website

Re: Plugin filtering for admin list pages

I think this would be great. I’ve had a few ideas that I wanted to tackle that would have benefited from being able to edit the output lists in the admin to exclude certain things.


Shoving is the answer – pusher robot

Offline

#5 2009-09-13 16:03:47

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,721
Website

Re: Plugin filtering for admin list pages

Just an addendum to this mod. If you’re mad enough to use it in its above version, some plugins (e.g. lam_browseby) will show their content twice on the page because that plugin hooks into the event="list" and ignores ‘step’ — since there isn’t normally a step associated with the list page, this makes perfect sense.

The temporary solution, albeit mucky, is to rename the event for this mod, for example:

$criteria .= callback_event('list_filter', 'criteria');

And then use that event in your register_callback()s instead. There’s probably a far better way to achieve this kind of functionality.

Last edited by Bloke (2009-09-13 16:04:17)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2012-07-17 23:49:14

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,721
Website

Re: Plugin filtering for admin list pages

Reviving this thread. Looking ahead to an unspecified version of Textpattern > 4.5.0, I think there’s a use case for plugins to be able to alter the list pages. For example (as mentioned above), to omit certain sections or authors from the list. A “show only your assets” plugin would then be a cinch to write, if a callback similar in concept to the one I proposed in the OP was applied on the pages of all core types.

There are three main problems though:

  1. Security
  2. Security
  3. Plugin contention

Point (1) is potentially massive and should really occupy two slots in the list: if a plugin could rewrite or append to the SQL statement then any kind of injection imaginable is possible unless some hardening is applied, akin to the kind of avenue net-carver mentioned above.

Not sure if point (3) is a concern for regular callbacks (istr pluggable_ui can only service one plugin at a time and one will overwrite the other, not augment it) but if two plugins try to alter the same SQL statement on a list panel then there could be big time breakuality.

So my question is whether this concept could ever make it to core and, if so, in what capacity would the core have to be altered to ensure it could be done safely?

Any ideas anyone?

Last edited by Bloke (2012-07-17 23:50:56)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#7 2012-07-17 23:59:45

mrdale
Moderator
From: Walla Walla
Registered: 2004-11-19
Posts: 2,203
Website

Re: Plugin filtering for admin list pages

no ideas, but if it let’s me cull one section (that’s 90% of the articles, but edited 1% of the time) from the articles page, I think I’m plus one-ing this bad boy [+1?]

Offline

#8 2012-07-25 21:42:24

etc
Developer
Registered: 2010-11-11
Posts: 3,863
Website

Re: Plugin filtering for admin list pages

What makes the existing callbacks more secure than this one?

Offline

#9 2012-07-25 21:51:26

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,721
Website

Re: Plugin filtering for admin list pages

etc wrote:

What makes the existing callbacks more secure than this one?

Hmmm, good point. I guess anyone could write a plugin that hooked into any of the callback points and execute some SQL that dropped the entire database.

In which case, the only consideration is making sure the final statement — which may be the result of more than one plugin tinkering with the where clause — is valid SQL to avoid (or at least minimise) ugly error messages. Or do we turn a blind eye to this as well: caveat utilitor?

Last edited by Bloke (2012-07-25 21:54:13)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#10 2012-07-25 22:40:03

Gocom
Plugin Author
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: Plugin filtering for admin list pages

I second etc. I do not see any security hazards relating to this new potential callback.

Bloke wrote:

which may be the result of more than one plugin tinkering with the where clause — is valid SQL to avoid (or at least minimise) ugly error messages.

If this callback only allows appending new filtering rules to the where clause, then the quantity of plugins will not have an effect to the statement’s validity in terms of actual errors. There is always the case that filters get too tight or contradict each other, giving you no results. But honestly, I don’t see that as an issue either.

Or do we turn a blind eye to this as well

I wouldn’t worry about validation much. I think it’s best to keep things as simple as possible. For instance, adding just a callback_event in the SQL statement’s where clause would be enough as far as I see. Developers know what they can do and can not. If you really want you could make so that the callback functions’ returned values are joined with a forced “and” operator, but even that isn’t necessary. If the callback_event is placed at the beginning of the statement, then developers know that they will need to end their added statement with an operator to keep things working. If someone (like me, doh) screws up and writes bad code that breaks shit up, then its not the core’s fault.

I mean, filtering and security related sanitation are needed for public facing access points and everything used by end-users and frontend. Due to the nature of the platform itself, same isn’t true for programs running internally.

Last edited by Gocom (2012-07-25 22:41:11)

Offline

Board footer

Powered by FluxBB