How do you pass a field variable along with the $id to a script?
How do you pass a field variable along with the $id to a script?
In our (laravel) controller file we have this field:
Field::inst('articles.demo_profile'),
I'm trying to figure out how to pass it to a script.
// ->on( 'postEdit', function ( $editor, $id, $demo_profile, &$values ) {
->on( 'postEdit', function ( $editor, $id, &$values ) {
$demo_profile = $values['demo_profile'];
$scriptPath = base_path('resources/views/public/whatever.php');
// exec("php $scriptPath $id $demo_profile"); // errors
exec("php $scriptPath $id"); // works fine
} )
Without $demo_profile it passes the $id fine and the script executes.
If I uncomment the line with $demo version and edit/save in DTE it errors with
Undefined array key "demo_profile"
This question has accepted answers - jump to:
Answers
will contain the value submitted.
Please, at the very least use
escapeshellarg
to sanatise the input. You are allowing user input to be run as a shell script - that's a serious attack vector. I'd suggest sanatising the heck out of that! Imagine a submission of; rm -Rf /tmp/*;
or worseAllan
In this case the only an administrator can execute the script and also the only values are Yes or No.
Coincidentally when I was doing UNIX tech support 25+ years back one of our Help Desk staff signed into a user's computer as root and did:
rm *
That rustled some feathers.
Okay passing the $variable works. However we have another problem. The $variable is passed to the script. The script needs to run several indexing queries.
What I am finding is that if I do an UPDATE or SELECT query of the ARTICLES or another leftJoin table that the query fails. With other tables there is no problem.
Are these tables locked for editing or something similar? Or perhaps is there another options other than postEdit which will get us there?
->on( 'postEdit', function ( $editor, $id, &$values ) {
Awesome - add
if
conditions for those two values and throw on anything else. Good security practicelol. The worst I ever did was
chmod -r 000 *
in a directory which had a hard link to/
. Sigh.Not explicit, but it does do it in a transaction which might be what you are running into. You can add
->transaction(false)
to stop that behaviour have just have it write immediately.Allan
I am exploring user error. Sit tight, thx.
There is security built into Laravel, enough? Maybe not. For all the $variables we are passing they are contained through a DTE select in the form. And the form is only access with Admin/Manager access, no public. Certainly it can be improved.
I changed the way the data is set up and passed to the include script.
Then
And:
This made it a lot easier to associate the $values in the script. It is working well now, thank you.
For this - I'd err on the side of caution. For the sake of an
if
andthrow
statement, it doesn't seem worth taking the risk of a remote execution attack.That it is from the admin page should be okay (assuming this Ajax script is protected with an admin check as well as the HTML for the page).
Good to hear that it is working now
Allan
Oops one more question, of course. I also have to execute the script after creating a new entry. This gets us to the script fine but the additional fields are devoid of life.
Sorry, what additional fields? I would suggest adding the fourth parameter to the
postCreate
event handler -$row
. That contains the row data as it has been read back from the database.Allan
If it wasn't clear or I misunderstand... I thought &$values was there for the column data in the table. It works with postEdit, but not postCreate.
With postCreate will $row work like this?
$city = $row['articles']['city'] ?? '0';
$region_code = $row['articles']['region_code'] ?? '0';
$country_code = $row['articles']['country_code'] ?? '0';
Something like that?
Yes. The documentation for this is here.
In
postCreate
the difference is$values
contains the data submitted by the client, while$row
contains the data read from the database. It should contain all the data you need.I'm not sure why
$values
would be empty inpostCreate
- however, are the values needed in$row
?Allan
With that last parcel of response about $row I think we have this resolved. Thx.