Request: 4.6.1 When saving an article with embedded PHP, ...

ande · 2016-10-11 08:35:30

… I get no indication that PHP code will not be executed if the original author has not at least the required permissions (Editor?)

A coworker has left the company, so I’ve set his account on “no permissions”. I still have these permissions, but whenever I edit an article of his with embedded PHP code, I get no notice about the PHP being “switched off”.

Also, I suggest there should be an option to take ownership of articles, at least for super admins.

Andreas

Bloke · 2016-10-11 08:50:51

ande wrote #302083:

A coworker has left the company, so I’ve set his account on “no permissions”. I still have these permissions, but whenever I edit an article of his with embedded PHP code, I get no notice about the PHP being “switched off”.

Interesting. Not sure how to handle this, but we’ll give it some thought and see if any sensible solution can be found.

Also, I suggest there should be an option to take ownership of articles, at least for super admins.

If you delete his account you get the option to reassign everything owned by him to a new user. Be warned that doing so changes original authorship to the nominated account, so if you want to preserve that information (perhaps it says “Written by Author A”, on the public site) the only way is to do what you have done and set their permissions to None.

colak · 2016-10-11 10:53:24

ande wrote #302083:

… Also, I suggest there should be an option to take ownership of articles, at least for super admins.

There is. You have to go to Write>articles. Select the articles you wish to transfer to another user by checking their checkboxes, go to the bottom of the page and use the pull down menu to change the author.

Bloke · 2016-10-11 11:00:14

colak wrote #302086:

Select the articles… go to the bottom of the page and use the pull down menu to change the author.

Haha, how did I forget about this?! Good call. Although, as with deleting and reassigning assets, ownership does mean authorship changes too. So any <txp:author> tags return the (re)assigned author. Txp doesn’t have owner/maintainer privs separation.

michaelkpate · 2016-10-11 14:01:32

ande wrote #302083:

A coworker has left the company, so I’ve set his account on “no permissions”. I still have these permissions, but whenever I edit an article of his with embedded PHP code, I get no notice about the PHP being “switched off”.

I am thinking changing the password with rah_change_passwords and setting the user to a role with extremely limited user permissions via bot_privs could be a solution.

etc · 2016-10-11 14:59:35

michaelkpate wrote #302089:

I am thinking changing the password … could be a solution.

Nice solution (you can actually replace his txp_users.pass field with yours), but leave his account with enough privs (2?) to run php code.

Bloke · 2016-10-11 14:59:52

Just had a quick look in the code. The allow_article_php_scripting is a simple global flag that is not assigned to any particular priv level. It’s not enforced at a user level at all, in fact.

The only place it’s used is when the <txp:php> tag is parsed, and is a simple binary decision: Is it allowed? Yes, execute the tag, else skip it. Same with allow_page_php_scripting.

So the option to show a warning on save doesn’t make sense. Unless I’ve missed something.

@ande: were you seeing some behaviour that prompted you to raise this issue?

etc · 2016-10-11 15:32:13

Bloke wrote #302091:

The allow_article_php_scripting is a simple global flag that is not assigned to any particular priv level. It’s not enforced at a user level at all, in fact.

The only place it’s used is when the <txp:php> tag is parsed, and is a simple binary decision: Is it allowed? Yes, execute the tag, else skip it. Same with allow_page_php_scripting.

Yes, but it looks like an additional check for has_privs('article.php', $thisarticle['authorid']) is done for article scripts..?

Bloke · 2016-10-11 18:22:24

etc wrote #302094:

Yes, but it looks like an additional check for has_privs('article.php', $thisarticle['authorid']) is done for article scripts..?

My bad, I missed that.

In which case, a simple check for article.php privs and a regex for txp:php on article save is all that’s required, with an appropriate message appended to whatever is already going to be returned? Presumably we wouldn’t trigger it on author multi-edit changes!

maverick · 2016-10-11 22:31:24

Aside: I always preferred ajw_workflow because it let me set ownership right from the article. Minor thing – just a bit faster for my situation.

Wondering: Is it worth look at separating owner and author in the core? Most corporate/organizational sites will have people come and go. Ownership will need to change, but it’s still appropriate to leave the author. Given that ownership is in the core, the simplest solution is to add author. Or maybe even allow multiple authors for a single article – because that happens quite often in certain circles like education . . .

bici · 2016-10-12 00:05:04

Should we have granular control of user rights at various levels by Sections and Articles within the Core? And that these rights could be withdrawn and users deleted or downgraded to no rights. This would be most desirable for sites that have many editors and or authors.

etc · 2016-10-12 07:56:19

Bloke wrote #302096:

a simple check for article.php privs and a regex for txp:php on article save is all that’s required, with an appropriate message appended to whatever is already going to be returned?

We could integrate this check into Validator, but I’m not convinced it’s worth doing, since there are many ways to alter an article (plugins…) without triggering this check. Moreover, some plugins (rah_function, etc_query, ...) require admin privileges too, and we can’t regex them all. A debug warning on the public side remains the best option for me.

maverick wrote #302098:

Wondering: Is it worth look at separating owner and author in the core? … Or maybe even allow multiple authors for a single article …

Both valuable for me, I meet this “team” articles situation quite often.

Textpattern CMS

Textpattern CMS support forum

#1 2016-10-11 08:35:30