Once upon a time, I discovered a bug in some JavaScript. I went off to investigate the source, only to find… the JS wasn’t coming from a file. It was being generated by a server-side method. Through string concatenation. It was a simple generation, something along the lines of:
jsCode += "location.href = 'foo?id=" + someIdField + "';\n";
Bad, but a minor WTF- and the bug was caused because someIdField
contained characters which needed to be escaped. It was actually unnecessary, and I could construct the logic completely on the client-side, which is what I ended up doing in that case.
I bring that tale up, because Konstantinos T has a special case of anguish.
<script>
function droppy(droppy_id, max_files) {
var droppy = new Dropzone(dropzone_name, {
//(...)
init: function() {
this.on('addedfile', function(file) {
//(...)
var edit_button = '<?php ob_start();
include(__DIR__.'/dropzone_edit_button_template.php');
$include = ob_get_contents(); ob_end_clean(); echo str_replace(PHP_EOL, '', str_replace("'", '\\\'', str_replace('"', '\"', str_replace("/", "\/", str_replace('__script__','script',$include))))); ?>
';
//(...)
Here, we see a client-side JS variable named edit_button
. Stare at the variable initialization. What you see before you is a dank abyss, a gaping hole with a bottom so deep that the bottom may as well not exist. Here, we stand at a precipice.
The value of edit_button
comes from PHP code, executed on the server-side. The actual template comes from an external PHP file, dropzone_edit_button_template.php
. But that template, the result of all the other methods called here, returns a string that may not be safe for JavaScript, like my simple bug above. Thus, the chain of str_replace
calls, nested one within the other.