Dump frame arguments below the source code #387
Conversation
…umper::dump HtmlDumper::dump calls HtmlDumper::setOutput and this method resets the headerIsDumped property every time the $output argument changes. This results in including the global styles and scripts on each dump. We prevent this from happening by reusing the same HtmlDumperOutput object.
Tries to be as close as possible to the source code syntax highlighting.
jonasdt
changed the title
|
👍 can you squash it? :) |
| $('.sf-dump-expanded') | ||
| .removeClass("sf-dump-expanded") | ||
| .addClass("sf-dump-compact"); | ||
| $(".sf-dump-toggle span").html('▶'); |
There was a problem hiding this comment.
please use a html sequence instead of a UTF8 char (to make it work on non utf8 websites)
|
really like it. besides the few nits I commented above it looks like a better alternative to my initial PR @jonasdt thx for picking it up. |
|
@staabm I've made the changes (except for the static variable thing). I can squash the commits if it is required. |
|
👍 |
|
Please merge this! It is really nice to have arguments, especially when working with templates where multiple variables might be passed through the same functions. Determining what variable is causing an issue is extremely hard when no arguments are visible. |
|
Looks great |
|
Any news about merging this request? |
|
+1 |
|
I will get to it, sorry for the delay. |
|
Any updates? |
|
|
|
Guys wait a bit, maybe @denis-sokolov has a bit to do the last past days |
Dump frame arguments below the source code
|
@denis-sokolov @staabm @jonasdt Doesn't this "dump frame arguments" change have some security implications? Just like $_SERVER and $_ENV, stack frame arguments might contain security-sensitive data, such as credentials or API keys and tokens. Perhaps the blacklist feature must expand to cover arguments as well ? Here's a somewhat real example: imagine a method/function that takes credentials as arguments and uses them in a Guzzle request, but the request fails and an exception is thrown; the exception message itself might not contain any sensitive data (although, sometimes they do - mainly tokens and API keys), but when you start looking at the backtrace, you are going to see the credentials as the arguments in the stack frame. EDIT: I think I managed to find a better example, database connections. Here's a page I found googling for "Whoops! There was an error". It is an old Whoops version, but is fine to illustrate my point: the PDO::__construct() is in the backtrace, and if the arguments are dumped, you can see them:
|
|
I think you have a valid point. Please open a new issue |
|
It is not important for our workflow as we only use Whoops in development, but I understand your point that some people might forget to disable it on production. The same can be said about |
|
Running it in production is not a valid use-case. Nevertheless I feel a blacklist for some sensitive parameters makes sense though (people which can access a development machine are not necessarily the ones who should know all the security related tokens/passwords etc. Involved) |
|
I thought about this more today and there are several places where sensitive informations can be exposed. It is not just the data tables and the arguments dump, but sometimes also the exception messages, and the source code chunks. Blacklist needs more wholistic approach, but even if there is such a solution, I agree that this is all meant to be used for development only. I've posted another idea I have about how to "hide" Whoops on non-development environments at 604 |
This builds on top of #337, but dumps the arguments below the source code (similar to #384).
Collapsed by default:
http://imgur.com/9augmq7
Expand second argument:
http://imgur.com/oXfrSfa
Expand first and second argument:
http://imgur.com/JJQ1oF0
No arguments:
http://imgur.com/uWVch0e