Forms with strange behavior

Myusername · 2020-12-24 13:23:23

I am using forms to insert embeds in my publications. Twitter, youtube, instagram and etc. However, lately I’ve been noticing a little strange behavior that I can’t identify the problem.

For example, when I add an embed from Youtube, I should write the following:

<txp::youtube url="https://youtu.be/sY8gUtyeAKE" />

Here is the code of the form:

<txp:variable name="video_id" escape="tidy">
    <txp:php>
        $url = parse('<txp:yield name="url"/>');
        preg_match('%(?:youtube(?:-nocookie)?\.com/(?:[^/]+/.+/|(?:v|e(?:mbed)?)/|.*[?&]v=)|youtu\.be/)([^"&?/ ]{11})%i', $url, $match);
        $youtube_id = $match[1];
        echo $youtube_id;
    </txp:php>
</txp:variable>

<txp:if_variable name="if_page_amp" value="1">

    <div class="amp_video_wrap">
        <amp-youtube data-videoid='<txp:variable name="video_id"/>' layout="responsive" width="480" height="270"></amp-youtube>
    </div>

<txp:else/>

    <txp:if_yield name="full">
        <div class="p_video full video_wrap">
    <txp:else/>    
        <div class="p_video alinhado video_wrap">
    </txp:if_yield>

        <iframe src='https://www.youtube.com/embed/<txp:variable name="video_id"/>' frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

    </div>
</txp:if_variable>

I would say that everything is correct, even because everything works as expected, except that SOMETIMES NOT!

And when this bug happens, I just have to duplicate the publication and the form will work again. That is, this is not an error in the code, because I duplicated the article, so everything is exactly the same! But one works, the other doesn’t. Any explanation for that?

Myusername · 2020-12-24 13:30:22

Okay, I think I managed to find the “problem”. Users who have lower privileges cannot add php to articles, correct? Any way for me to get around this?

Bloke · 2020-12-24 13:54:21

Only publishers and managing editors can put PHP in articles (as long as the corresponding pref is set).

Yes you can get round it either by hacking admin_config.php to widen the permission scope there to lower tier user (not recommended unless you want to repatch after every upgrade).

Or, write a tiny admin plugin that runs on the Write panel and tinkers with the global $txp_permissions array. If you set that plugin to run low (below 5 load order) then it should kick in and alter the values in time so the panel will honour the save request that includes the PHP. Untested, but it should work.

Bloke · 2020-12-24 13:57:02

Btw, there is a plugin: bot_privs I think. Or rah_privileges or something, I forget. These allow you to mess with the permissions en masse.

My smd_user_manager also does, but that’s more of a sledgehammer and doesn’t work with the most recent (Txp 4.7+) versions yet.

Myusername · 2020-12-24 15:35:25

Users with low privileges cannot add PHP to articles, and that seems right to me.

But when it comes to the forms added to the articles, does that make sense? Anyway, only those who have access to them can create forms. No user with low privilege could add any PHP to the article, except through a form that can only be created by a user with the necessary privileges for that. That way, it would not limit users to using forms. And if it is the case that the administrator does not want the form to be used by a group of users, use txp:if_logged_in.

That was just a thought I had. Thanks for clarifying and giving me some options.

etc · 2020-12-24 23:31:23

That looks reasonable (and easy to do), though not totally bw-compatible. Thoughts?

jakob · 2021-01-05 14:48:05

Myusername wrote #327790:

… No user with low privilege could add any PHP to the article, except through a form that can only be created by a user with the necessary privileges for that. That way, it would not limit users to using forms. And if administrators want to restrict a form’s use to a group of users, they could use txp:if_logged_in.

I’ve come up against this several times before. To get around this, I even went as far as making a mini plugin where a shortcode tag would have sufficed. So, I like Myusername’s suggestion. In summary that would be:

Low-privilege users can’t add txp:php directly to an article (as before).
Those same low-privilege users don’t have access to editing forms / pages (as before, I think).
Permit txp:php when encapsulated in a form called via a shortcode or output_form. Users are unable to edit it, so the onus is on the developer/admin to ensure it is safe.
Perhaps check that txp:php can’t be passed into a shortcode form via a yield statement or attribute.

Could we then regard that as being “sufficiently secure” against misuse by guest users?

Bloke · 2021-01-05 15:43:20

jakob wrote #328045:

Low-privilege users can’t add txp:php directly to an article. Those same low-privilege users don’t have access to editing forms / pages.

Yes, I think this is how it works now. Would have to check.

Permit txp:php when encapsulated in a form called via a shortcode or output_form. Users are unable to edit it, so the onus is on the developer/admin to ensure it is safe.

That sounds reasonable.

Perhaps check that txp:php can’t be passed into a shortcode form via a yield statement or attribute.

I think this happens now already. Not sure. Here’s my simple test:

Ensure prefs Allow PHP in articles and Allow PHP in pages are enabled.
Create Form php_inject (content shown below) as a Publisher/Managing Editor user.
Create article ‘PHP Test’ (content shown below) as a Copy Editor user.
View the article. Result: Tag error: Textpattern Notice: Author is not permitted to use PHP code. while parsing form default on page default for both PHP blocks.
Duplicate the article as a Publisher user. Just click Save.
View the article. Result: Code runs as expected.

Form php_inject:

Running injected:
<txp:yield name="php" />

Running embedded:
<txp:php>
global $thisarticle;
dmp($thisarticle);
</txp:php>

Article:

<txp:output_form form="php_inject" php='<txp:php>global $pretext; dmp ($pretext);</txp:php>' />

So, from that, it seems as if passing PHP into forms is already forbidden IF the article is created by an author who does not have article.php privileges. So we must be checking the author name at runtime.

BUT, interestingly, Copy Editors have the ability to edit published articles, so if you switch back to your Copy Editor account, you can make changes to the Publisher’s original article, alter the PHP, save it and have your modified PHP code executed.

This definitely has merit as an idea. Having PHP ‘hard-coded’ inside a form should be permissible, but passing it in should not. A few questions/caveats:

Can we detect the difference between code passed in from a restricted account vs code already added to a shortcode/form by a more trusted user?
Would execution still be forbidden if ‘allow PHP in articles’ is off? Or is PHP in forms governed by the ‘allow PHP in pages’ pref?
What happens if someone uses an override form that contains PHP, when the prefs are in various states?

Either way, I think we need to review some of these user levels and their privileges as part of this.

Last edited by Bloke (2021-01-05 15:47:18)

etc · 2021-01-05 16:37:41

Bloke wrote #328048:

BUT, interestingly, Copy Editors have the ability to edit published articles, so if you switch back to your Copy Editor account, you can make changes to the Publisher’s original article, alter the PHP, save it and have your modified PHP code executed.

DOH! Hilarious, as Jukka used to say. We should either enable PHP for Copy Editors or forbid editing admin articles or check LastModID when parsing <txp:php />.

Bloke · 2021-01-05 16:51:40

etc wrote #328050:

DOH! Hilarious, as Jukka used to say. We should either enable PHP for Copy Editors or forbid editing admin articles or check LastModID when parsing <txp:php />.

I’m fine with any/all of the above. Whatever makes most sense when we review the privs. Or, y’know, now in 4.8.5 if we want to close the hole.

etc · 2021-01-05 16:58:20

It looks like CE can edit Forms anyway, so option 1 for me.

Bloke · 2021-01-05 17:04:30

etc wrote #328053:

It looks like CE can edit Forms anyway, so option 1 for me.

That makes sense. If we trust them to edit forms that can have PHP in them, then there’s not much issue with allowing them to do that in articles too.

Textpattern CMS

Textpattern CMS support forum

#1 2020-12-24 13:23:23