I am trying to create a Herald rule to block commits with empty commit messages. The rule is a global rule that applies to Commit Hook: Commit Content. Unfortunately, I have been unable to get the rule to trigger with the Test Console.
This led me to try altering the conditions in various ways, ultimately trying this:
When any of these conditions are met:
Always
Take these actions every time this rule matches:
Block push with message: No empty commit messages allowed.
It seems like this should cause Phabricator to apply this rule to any commit, but according to the Rule Transcript even this rule is not applied.
Should it be? If so, what might cause this behavior?
Through discussion in the #phabricator channel on irc.freenode.net, I learned that testing pre-commit Herald rules with the Test Console is not currently supported by Phabricator. The developer that helped me created a task for this issue, which can be found here https://secure.phabricator.com/T9719.
With the Test Console not an option, I am not entirely sure how to test Herald rules of this type without allowing unacceptable commits into the repository. I had read this https://secure.phabricator.com/book/phabricator/article/diffusion_hooks/ page, which explains how to install custom hooks. Interestingly, it states that "These hooks will run only after all the Herald rules have passed and Phabricator is otherwise ready to accept the commit or push." I asked whether it would be possible to create a hook of this type to deny all commits and then test the Herald rules by actually trying to make commits as normal. It was indicated that this might work. I haven't had a chance to test this yet, so I will post an update once I know more.
Related
Virtually all SecRule examples for modsecurity whitelisting I found on the web include turning off the rule engine, example:
phase:1,nolog,allow,ctl:ruleEngine=Off,id:23023
However, as far as I got it from the documentation, "nolog" combined with "allow" should have exactly the same effect already - namely disrupting rule processing and preventing any log entries. Hence, wouldn't the following configuration be absolutely equivalent?
phase:1,nolog,allow,id:23023
If I am wrong, where's the difference between the two?
I am using modsecurity 2.9.3.
I’ve not seen that before but I can take a guess why it’s there.
The allow action is a disruptive action. When ModSecurity is working in DetectionOnly mode then disruptive actions (including allow) are not actually actioned. This means any subsequent rules are still run - even though they would not be run when running in the normal On mode. This can make the logs very noisy, and also make you think you have to tune more rules which you do not actually have to tune.
The ctl action is not disruptive and so does execute even in DetectionOnly mode. Therefore by adding ctl:ruleEngine=Off to any allow rules you can have only the real errors logging in Detection only mode.
I’ve actually done the opposite and used ctl:ruleEngine=On to make the allow action take effect even in DetectionOnly mode. For example I have a rule, near the beginning of all my rules, to look at GET calls with no params to index.html pages and say they are reasonably safe so no need to run rest of rules on them. This saves processing time and false flags.
I made a herald rule that had an unintended effect on some tasks in my project. I need to be able to look up the historical log of all the tasks that had the rule applied to them to fix the tasks that were erroneously affected by the rule. Is there anywhere in herald or phabricator that let's me do that?
There is not conduit endpoint for Herald, so you have to check in https://your phabricator/herald/transcript/ where all the Herald action trace lies
Firestore can take up to 10 mins to propagate newly updated security rules, says Firestore. So instead of patiently waiting for 10 mins for every updated security rules, how else can we tell that the security rules has been propagated successfully. So one does not need to wait for 10 mins and 1 second later to test the behaviour?
There unfortunately is no built in notification that the new rules have been deployed. You will have to test something about the change you made to the rules to see if they've been deployed.
For example: if you added a new validation that disallows writing a certain field, try writing with that field. Once that write fails, you know that the new rules are deployed.
As J. Doe commented, usually it takes much less than the advertised 10 minutes before the rules are deployed. In practice, I frequently see that my updated rules are deployed by the time I've modified the code to deal with the change.
You can check the Firebase Console (on the firebase.google.com website). Your rules display there under the Rules tab.
...without actually saving data to that node?
For example, I have a chat app. I'd like to check whether a user has write access to a node before showing the "Send message" button.
Define another node with the exact same set of security rules, that exists for no reason other than to perform these checks, and attempt a write there first to see if it finishes without error.
The most common approach is to replicate a similar, simplified version of the rules in your application code. You'd typically only replicate the benign checks, and leave extra validations against malicious users solely on the server.
Although I must admit Doug's version also sounds interesting. :-)
I am sending out a nightly email through rules scheduler, when I manually execute it sends out one email as it should, however when it runs on the schedule it sends me 10 duplicate emails. I've looked all over and can't seem to find any solution to the problem.
Thanks in advance for any suggestions
Use Job scheduler module. In this module you first insert the data in job_schedule and create a queue for each schedule . when crons run it start executing each queue and send mails then it delete its entry from the job_scheduler table. hence it will not send same mail again and again to the same person.. There is proper documentation in job_scheduler module in drupal7. Just go through it.
This sounds like a bug in the Rules module; it has its quirks. I see you have reported this issue in the Rules issue queue: http://drupal.org/node/1314916, which is what I was first going to suggest. So now I know your issue is for Rules 7.x-2.x dev integration with Views 7... both of which have more than a few bugs. I strongly suspect this issue has as much to do with Views as with Rules. (The 10x repetition seems unlikely to be a coincidence since 10 is a default value for results-per-page in Views, etc)
When you report an issue, it's helpful to include all pertinent information (Drupal version, steps to replicate, what's written to the log, etc). I'd personally suggest seeing if you can replicate your issue in a clean installation of Drupal with just the modules necessary to run your test. If you can replicate it that way, it's easier to provide enough information for the developers to identify the issue and resolve it. (e.g. use Devel generate to create some nodes and dummy users, then create a very simple view, e.g. just titles of the five most recent nodes, and use that view as the source for your email content. Does it send 5 copies? You may need to configure a localhost mail server to test this.