[Résolu] Security BUG or FEATURE? Conditionals static values and custom functions params

[Auteur]

Publications

[henrikG]

Hello Support.

I have been working on conditional display of some content based upon if the user has access to a membership or not.
I use WishList member to manage the membership.

Wishlist member can handle inline content by a shortcode [wlm_private "<Memebershipname>"] THE CONTENT [/wlm_private]

So if the user is member of the membership, then "THE CONTENT" will be displayed.

Now in order for me to use this in a toolset condition I have considered to register it as a shortcode, but since the membership name is dynamic it makes no sense to register all sorts of short codes that I use on the site.

So I created a custom function that would take the shortcode string as a parameter, call do_shortcode and return the return value, which then could be evaluated with a static value in a toolset conditional block.

During debug I noticed that the actual string parameter handed to my custom function was the RENDERED outcome of the shortcode, not the shortcode as the string it was entered in the parameter field. And even if I did not even register the shortcode it would still render it, so basically the function did not work because the parameter was not a shortcode but the outcome of the shortcode.

So somewhere in the core of toolset, the parameter string will discover if the parameter string was a shortcode and render it, even if I have not registered it.

That made me think if I could simply make that function redundant by using the static value comparison and place the short code inside a static value. (which basically changes the static value to a dynamic value)

And Yes this was possible, so instead of using a custom function I can simply compare two static values because somewhere in the core of toolset all string values gets rendered in case they hold a short code.

Now this can be a security bug because you are able to execute short codes without registering them, but it could also be the way the system is designed on purpose, and I will be able to expect this behaviour to continue going on forward.

Either way I need to know if its a bug or a feature, that parameter strings gets rendered if they include a short code, which is the same scenario for static values.

Please see this video for an illustration.

hidden link

Cheers.

[Waqar Supporter Languages: Anglais (English ) Timezone: Asia/Karachi (GMT+05:00)]

Hi,

Thank you for contacting us and I'd be happy to assist.

For what you've shared, a short answer is that it is expected and in fact intended behavior that any shortcode or custom function used in the conditional display evaluation is automatically expanded or processed.

A longer explanation with some background context is that one of the key flexibility of using Toolset conditional display is its ability to evaluate based on the output of shortcodes and PHP functions:
https://toolset.com/documentation/legacy-features/views-plugin/using-shortcodes-in-conditions/

And if you'll check the conditional statements with static values, shortcode, or custom function, you'll see that the format is the same, without any distinction based on the type of these items. In the GUI for the conditional display, yes, there are separate dropdowns for static value, custom shortcode, and functions, but, that is only for organization and/or ease of use. If you'll switch to the advanced editor, you'll see that structurally, the condition statement format will be the same.

This flexible conditional format means that the system will need to prioritize the processing of shortcodes and custom functions before the actual evaluation comparison can be effectively made.

To be honest, I can't think of any practical scenario where someone would want to pass the unprocessed shortcode as a static value as a parameter for a custom function. However, if it is indeed needed, you'll need to pass it in a way that it can't be recognized as a shortcode.
(for example, you can pass the shortcode without any square brackets or pass the shortcode name as a first parameter, and any shortcode attributes as subsequent parameters, etc)

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

[henrikG]

> To be honest, I can't think of any practical scenario where someone would want to pass the unprocessed shortcode as a static value as a parameter for a custom function.

Well I can 🙂

My custom functions saves the shortcode as a key in an associated array, as well as the outcome of the do_shortcode call
That way if the same custom function is used multiple times on the same content template I only have to render the shortcode once, so in other words I have cached the outcome of the shortcode, while the page is rendered.

If the rendering of the shortcode will perform queries to the database, then I am able to optimize it this way.

Now it may be that toolset does this also, so I am safe using the shortcode as a static value in my condition multiple times, or it may be that toolset actually performes the do_shortcode on every shortcode it finds while rendering the page. If toolset actually cache the shortcode outcome then there is no need for my custom function then.

Can you tell me how toolset handles if the shortcode are used in multiple conditional blocks in the content template?

Cheers.

[Waqar Supporter Languages: Anglais (English ) Timezone: Asia/Karachi (GMT+05:00)]

Thanks for writing back and sharing some background information.

It is an interesting use case and though I have a feeling that Toolset will process each instance of shortcode every time, I've requested some feedback on this matter from the concerned team.

I'll keep you updated through this ticket.

[henrikG]

Thanks.. I will look forward to your reply.

Cheers

[Waqar Supporter Languages: Anglais (English ) Timezone: Asia/Karachi (GMT+05:00)]

Thank you for waiting.

I've received confirmation from the developers and Toolset doesn't cache the output of shortcodes.

This means that if you're working with a custom function that is acting as a cache, you'll need to pass the shortcode in a customized string format that is not recognizable as a shortcode, or otherwise, it will be expanded/processed. Inside your custom function, you can always decode that custom string into the equivalent shortcode.

[henrikG]

Ok Thank you Waqar.

I will build a special function that does not take a shortcode string as a parameter then 🙂

[henrikG]

My issue is resolved now. Thank you!