> My first reaction when I read this was "You shouldn't" 😅...
* this was my first reaction as well; in many years of BD and Drupal dev I've never had occasion for this; so i'm curios as to what your use case is.
> Can I do this securely?
depends on a lot
what is the bash script doing? is just `ls` then prolly fine
who can access it; admin only; everyone?
> Can anyone point me at any existing sample code?
@bwpanda has shown how `drush` is doing it; should work in backdrop too, but it should be pointed out a `drush` user is a cli user and already has access to cli and bash scripting ... that is a big difference
> How would I do this?
the how is in the `drush` example.
Might be better to tell us about your use case and find an alternate method to what you are trying to accomplish.
But I agree with everyone else, however that gets called needs to be completely locked down. My off the cuff suggestion is to not have this in a module, but have it embedded into a page and use the normal roles/permissions to lock the page down. Basically KISS.
However, it's not clear to me that this is a good option and I understand the concerns.
We are currently experimenting with another option. We have set up a script that runs on periodic basis. Each time the script runs, it checks the database for a new request. If there is a new request for a specific action, it runs another script on the server to fulfill that request.
In this case, the script is only looking for specific values and if that specific value is present, it takes the action requested.
This seems like it's a lot safer. Any thoughts?
Happy to discuss the specifics with anyone in Zulip. :-)
I figured the space part of it out, but caption length is still limited to about 125 characters. - #CboxContent: margin-bottom expands it just enough and doesn't disrupt the counter or arrows...
Hello,
Indeed, there is no more field than "login" and "mail address" (and password) in the "Create new user".
It seems indeed to be a bug, unsure if someone can reproduce on a fresh...
Does backdrop have a super admin that's different than users assigned the administrator role?
Sort of. Backdrop has an administer role that can be granted specific...
No, both those .json files are extant in the files/config_XXXXX/active folder.
Views UI wasn't enabled. I did so, and now I can manage content and people.
Thanks!
Comments
Here's an example of Drush calling the `fix-permissions.sh` script: https://github.com/backdrop-contrib/drush/blob/2b439610d644a0d82f541b047...
You could use that as a basis for your hypothetical code.
My first reaction when I read this was "You shouldn't" 😅...
...but if you are to, then I would suggest to also pair it with a
user_access()and/oruser_has_role()check.If you want to run the script while not logged in, then I'd also add a token to the mix (see how the cron URL token works).
> My first reaction when I read this was "You shouldn't" 😅...
* this was my first reaction as well; in many years of BD and Drupal dev I've never had occasion for this; so i'm curios as to what your use case is.
Might be better to tell us about your use case and find an alternate method to what you are trying to accomplish.
Ignoring "If you should..."
A Backdrop module is just PHP, so, first result from Google:
https://stackoverflow.com/questions/11052162/run-bash-command-from-php
# # #
But I agree with everyone else, however that gets called needs to be completely locked down. My off the cuff suggestion is to not have this in a module, but have it embedded into a page and use the normal roles/permissions to lock the page down. Basically KISS.
Best,
Michael
I did some experimenting and was able to run a bash script located within the Drupal directory using the php function:
https://www.php.net/manual/en/function.exec.php
However, it's not clear to me that this is a good option and I understand the concerns.
We are currently experimenting with another option. We have set up a script that runs on periodic basis. Each time the script runs, it checks the database for a new request. If there is a new request for a specific action, it runs another script on the server to fulfill that request.
In this case, the script is only looking for specific values and if that specific value is present, it takes the action requested.
This seems like it's a lot safer. Any thoughts?
Happy to discuss the specifics with anyone in Zulip. :-)