Adding a patch that addresses the issue.
daceej → changed the visibility of the branch 3511713-entity-usage-not to hidden.
Hi @yazzbe!
Thanks for the feature request!
I can tell you that this will not be included in the next release, however exposing all installed modules is something that is being planned for a future release.
Any additional information you can on your use case would be super useful as I'm also considering creating another module for pulling and aggregating data that vitals exposes.
This has come up again in https://www.drupal.org/project/vitals/issues/3474653 ✨ Report all installed modules Active .
Closing this issue in favor of carrying on the conversation over there.
@tijsdeboeck vitals_v2-2.png is perfect!
I'm going to add a "credits" section to the readme when I commit this. Do you have a preference on how I add your name?
@tijsdeboeck I'm open to the idea! I will reach out to you in the #vitals channel in the Drupal Slack. I am in the early planning phases for some changes to vitals to make it more robust and allow it to develop a better ecosystem. In fact, you have requested some of the features I'm trying to work in in previous issues :)
Committed! New release should be tagged in the coming days. I have one other issue I wish to include in the next release.
Working on getting this committed with a D11 release (apologies for the delay).
Hi @tijsdeboeck!
This is a great idea! Thanks so much for putting these together!
Of these I like vitals_v2.png the most.
Would you be willing to make one that is all black with a transparent background?
Using the current one for vitals extra could be neat because it would be the same logo just with the green graph, which would set it apart.
What do you think?
Patch has been committed and should be in a release here shortly!
Thank you for reporting (and the patch!!) @Glottus!
I will take a look and attempt to get an updated release out this weekend.
Hello @seeduardo!
Can you specify what sets Site Guardian apart from similar modules such as DRD, Vitals, and Monitoring on the product page and/or README?
It looks like the site_guardian_key will be exported as part of the Drupal configuration export. Many modules do this, but you may want to consider explicitly flagging this in the README or on the product page so that site maintainers can take actions as needed. Many site owners prefer to keep config items like this in environment variable or even directly in settings.php as an override.
The access check happening in checkActivationAndSiteGuardianKey() are potentially susceptible to timing attacks. The key comparison should be done using hash_equals() to mitigate.
if ($savedKey && (empty($site_guardian_key) || $site_guardian_key != $savedKey)) {
\Drupal::logger('site_guardian')->warning("Site Guardian request received but Site Guardian API access is denied.");
return "Access denied";
}
Finally, you should consider taking advantage of the Flood API. It looks like the module may currently open a site up to a brute force attacks while attempting to guess the key. Limiting the number of failed access checks via the Flood API would be a great way to mitigate that.
BTW - I am the maintainer of the Vitals module, which suffered from the exact same issues I'm flagging here. You can see the protections that vitals uses to address these concerns here.
Have not had much time to think through everything just yet. I have some projects that are wrapping up soon, so I should be able to devote some time to this shortly.
New tag for D10 will be cut in a few moments.
Committed!
New tag for D10 will be cut in a few moments.