Codit: Debug output from $_GET

codit_debug()

Drupal Documentation
This function appears in the Codit Module

Sometimes you need to debug something on the live server. It should generally be avoided, but sometimes you have no other choice. When you are stuck, Codit can be a lifesaver with codit_debug();

Codit allows you to create a debug slug that when passed in the query string, grants access to whatever output is triggered.

To use it:

  1. With Codit installed, go to /admin/config/codit or Configuration->codit Settings. Set your debug slug to something unique and obscure. Ex:"HalSaysShowMe"
  2. Make sure the correct role (your role) has permission to see the debug output /admin/people/permissions#module-codit
  3. In your code, or tpl where you need to echo out some values, call the function codit_debug() specifying what you want to output and what trigger you would like to cause this to output.
    <?php
    codit_debug    ($thing_you_want_output = $node, $trigger = 'node', $message = 'Here is the node object right before my code is breaking it.');
    ?>
  4. Now path your page and append ?{debugslug}={trigger} , so in this example you would append ?HalSaysShowMe=node

If you have the right permissions for your role, then the node object would be output to the page along with the message "Here is the node object right before my code is breaking it." If you have devel enabled, then krumo would be used to output the object. If devel is not enabled it will pretty print the object using print_r().

Function

<?php
/**
 * Checks permissions and presense of $_GET debug to output debug information.
 *
 * @param mixed $thing_to_output
 *   The array, object, number or string to output.
 *
 * @param string $s_trigger
 *   The value in the $_GET to look for to output debug  ?debugslug=[s_trigger].
 *
 * @param string $s_message
 *   An optional message that can accompany the output.
 *
 * @return bool
 *   Representing whether the user permission AND the trigger value
 *   was present in the GET
 */
function codit_debug($thing_to_output = array(), $s_trigger = '', $s_message = '') {
  // Check permissions to see if user is allowed to see debug.
  if (user_access('view codit debug output')) {
    // Check to see if kpr is available for nice ouput of arrays or objects.
    $f_output_it = (function_exists('kpr')) ? 'kpr' : 'print_r';
    // Get the site's debug slug.
    $s_debug_slug = variable_get('codit_debug_request_slug', 'debug');
    // Check the $_GET.
    if (!empty($_GET) && !empty($_GET[$s_debug_slug]) && (!empty($s_trigger)) && ($_GET[$s_debug_slug] == $s_trigger)) {
      if (!empty($s_message)) {
        $f_output_it("Message: $s_message");
      }
      if ($f_output_it === 'kpr') {
        $f_output_it('Debug Output: ');
        $f_output_it($thing_to_output);
      }
      else {
        print "<pre>\n";
        $f_output_it('Debug Output: ');
        $f_output_it($thing_to_output);
        print "</pre>\n";
      }
      return TRUE;
    }
  }
  return FALSE;
}
?>

Security Mitigation

There are several factors that make this fairly secure:

  1. The debug slug is custom. Reduce your risk by making a hard to guess debug slug.
  2. The user would need to have the "view debug output" permission. Reduce your risk by carefully assigning this permission.
  3. The trigger is custom. A user would need to know or guess the trigger. Reduce your risk by choosing hard to guess triggers.
  4. An attacker would need to meet all three requirements above in order to see the debug output.

section:

modules:

Feeds: