Posted by frob on December 26, 2011 at 4:10am
Hello anyone who has built custom drush modules.
I am writing drush integration into my event tracking module in the form of admin controls and I have a question about user permissions. I want to allow the creation of event tracking code to be added through a drush command. However, because this would be the equivalent of javascript injection, this would have the potential for a xss attack to be injected into the ga code. I want to limit this with the use of user level permissions, just as I would if this where a web based admin section.
I also intent to do input filtering on the output of the user created event tracking rules. So don't worry about that. I just have some questions about how drush deals with permissions.
Comments
I want to allow the creation of
Have you seen Permissions API? With that you can grant any permission you want by running something like
drush perm-grant 'authenticated user' 'create event content' --uri=dev.example.comThat said, I'm not sure I understand your use case. If Permissions API doesn't help, can you explain why do you want to create tracking codes from the command line?
My Module creates an event
My Module creates an event tracking api through the use of google analytics event tracking. The drush portion will just create an interface to allow an admin to add/remove event tracking rules as well as override the event tracking rules gathered from other modules from the event tracking api hook.
By doing this in the command line one would not have to push code to production or change any code at all on the site. This would allow for better usability testing to be done quickly.
Because this involves injecting user generated content into javascript, I would want to limit the ability of this to users with the proper permissions. I will look at the permissions API. Thanks.
EDIT : The Permissions API is not what I am looking for. This is more of a question of how to limit drush through the use of permissions.
Implement drush_hook_COMMAND_validate() ?
You can implement drush_hook_COMMAND_validate() (where command would be the name of your command) - see http://drupalcode.org/project/drush.git/blob/HEAD:/examples/sandwich.dru...
So you could pass through the uid to drush, check against whatever set of permissions you have, and if something shouldn't happen, run drush_set_error so it will not run the command.
I believe that is it. Thank
I believe that is it. Thank you.
So it looks like I can see
So it looks like I can see what user drush is running under in the same way as any drupal module.
What is really interesting about this is I cannot remember every running drush as a specific drupal user at any time in the past. Isn't this a bit of a security hole? Do drush modules typically do this and I am just unaware of it?
I the sandwich code it is only looking to make sure it is running with root on the server but is not utilizing drupal's user system at all.
Drush Policy files
Since you're using Drush you could also consider using a
Drush Policyfile. This is the topic I am covering tomorrow night at our monthly Meetup; now taking place at the Santa Monica Public Library.Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant
I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us
hmmmm Had I read this on
hmmmm
Had I read this on Monday I might have been there on Tuesday. Sorry, hope the talk went well. Was it recorded or was it a one time only thing?
Unfortunately, there were
Unfortunately, there were some technical difficulties and the talk could not be recorded (though my understanding is that this is part of a drush learning series that will eventually be up on Lynda.com, correct?). However, I was a little confused by the scope of policy files and it basically contains implementations of
drush_hook_COMMAND_validate()(I just didn't know that is what it was called ^_^). The big thing that I didn't get at the time I posted this is that you can have multiple policy files that implement the hook for the same command (so a production site could have a policy file consisting of policies that are on your staging site plus a policy file specific to the production site so it is more strict?). But as far as I can tell (and from my understanding from the Q&A with Chris), you do still have to implement validation for every command you wish to validate and you can't have a generic validation that would cover every command.so then, are the policies in
so then, are the policies in the scope of the site or the module? Meaning, since this is for a module should I not just implement drush_hook_COMMAND_validate and not use the policy file option. Remember that this is for a contribute module.
They can be in either
You can have your module / drush file implement its own hook (so if the command was 'super-duper-command', it could get drush_module_super_duper_command_validate() while someone else with their own policy file could implement drush_policy_file_super_duper_command_validate.
BTW, lighthouse technology group seemed to have some examples up at http://lighthousetechnologygroup.com/drush/examples/ which will hopefully be useful.
EDIT: Unless you just include a policy.drush.inc file with your drush.inc file. That might be the other way to go at it? Though thinking on it some more, I imagine it should be unnecessary. The hook is found, it should get called.