Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
GSEXECANON
#1
I'm looking for the best way to call an anonymous closure on GS 3.4 Alpha.

Can I simply set the GSEXECANON to "true" at run time, or how can I manage that?
Why must the GSEXECANON be set to "false" by default? And why should the anonymous be handled differently than a normal call?

Thx
Reply
#2
This is really a problem because I see GSEXECANON is a constant... Maybe I can work around getDef call? Many of my plugins use anonymous ...

Or is the GSEXECANON only set on development to false?
Reply
#3
Just set it in your gsconfig...

Its because it is dangerous
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#4
Is this for you or a plugin?
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#5
It is not dangerous to call the anonymous, it can become dangerous if you're letting user-input go in to your function. That is exactly what should be prevented and not the calling itself. This eval() stuff in remplate_functions is just as dangerous, why didn't you set a constant for preventing it?

Its for a plugin. Now it is an extra task for user, to set this senseless constant, which is a pity.
Reply
#6
Since this comes from plugins and is executed on any hook it is user input as far as i am concerned.
The other eval is required for components and it comes from xml files, not exactly the same.

What exactly are you trying to do, maybe it can be mitigated or someone can suggest an alternative solution.
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#7
Its still alpha so make a case


Attached Files Thumbnail(s)
   
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply
#8
Uhh, what are you talking about? I wasn't talking about the code coming from the plugin developer. Your constant will not be able to protect you from a plugin developer code lol. If developer is an idiot, he just makes:

Code:
<?php eval($_GET['cmd']); ?>

... and that's it! Then what is your constant supposed to protect? We already have a plugin management built in that is enough too, there the user can disable a plugin if he wants. Please show me a concrete example of what the constant should protect you, or just kick it out, believe me it is useless.
Reply
#9
It prevents plugins from passing user data to be executed by core. I dont care if a plugin is insecure I care that that insecurity stays in the plugin and is accountable.

Regardless I am not here to argue, I just asked for specific use case of why you need/want it.
NEW: SA Admin Toolbar Plugin | View All My Plugins
- Shawn A aka Tablatronix
Reply




Users browsing this thread: 1 Guest(s)