Always whitelist localhost and inform users why no console is displayed #104
+235
−92
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We get a lot of reports that a console isn't displayed when requested to. This can happen because of two things: a user is trying go request a console rendering from unauthorised IP or a user is trying to render a console on unacceptable page content type. For example, we try not to render the console on JSON pages.
I think most of the times, people try to whitelist a singe IP or a network, which currently leaves localhost unauthorised, because you have to explicitly specify it. This is well documented, but it is a tricky behaviour and I can't imagine a case where you want localhost out of the whitelisted IPs.
To remedy this I propose to have IPv4 and IPv6 localhost always whitelisted. This leave us a nice window to refactor and improve most of the code code around network whitelisting.
As noted in the first paragraph, network whitelisting is one of the places where console rendering could be blocked. Another one is content type based rendering. To help with this, I made
config.web_console.acceptable_content_types
, where a user can put customised set ofMime
types.And to make everything more explicit, I introduced logging when a console rendering is denied. This, again, is customizable and could be stopped with
config.web_console.whiny_requests = false
. Its on by default, so we can ask users to provide us the log and help us, and them, investigate issues further.