4 ms·
contentTypes[contentType] || contentTypes['default']; Don't do this. Untrusted user input could be anything, such as "hasOwnProperty" or "toString", for exampl
by jorangreef 7y ago
contentTypes[contentType] || contentTypes['default'];
Don't do this. Untrusted user input could be anything, such as "hasOwnProperty" or "toString", for example:
contentTypes['hasOwnProperty'] // [Function: hasOwnProperty]
contentTypes['toString'] // [Function: toString]
- your-nanny 7y agoI always thought the urge to replace switches with objects was fashionably bad advice. I get that the object literal approach feels more functional, and that forgotten break statements will cause havoc tho. Seems like a safeswitch construct is in order, that does not allow dropthrough. something like: safeswitch(s) { case 'alpha': calc(alpha(x), 2); case 'beta': calc(beta(x), beta(x*x)); } else { // default case here calc(x); } alternatively, switch could be modified so that passthrough is not the default, and so, instead of a break statement one would use a passthrough statement to enable that behavior (opt in instead of opt out)
- steve_adams_86 7y agoWhat are the implications of this? What could go wrong outside of runtime errors? When I've used this pattern in the past I've used a reusable 'getter' object which implements `hasOwnProperty` on itself for the sake of being sure I'm getting only the stuff I want. But it's not quite as concise as what's shown in the example, apart from getting the default internally rather than externally using ||. I didn't do this for security though, I did it for sanity - I don't want to get false positives when accessing, and the prototype has a ton of properties.