• (nodebb)

    Hypothesis: Someone had something that they already knew was safe, and wanted a way to get a pipe for it, and named the method "safePipe," as in a pipe for something known to be safe...without thinking about the fact that the next dev to come along, if they saw the method signature but not the implementation, was more likely to think it meant the pipe was safe rather than that the value being passed to it was supposed to be.

    Naming the first parameter "knownSafeValue" instead of "value" might almost make this acceptable, although I'd still say the method needs a better name. "nonSanitizingPipe," perhaps.

    As such, while it's pretty much an entirely semantic distinction, I'd personally call it highly misleading but probably not "least applicable." I don't so much object to others choosing to classify it that way as wish to express my own interpretation.

  • Conradus (unregistered)

    It seems the method would have been better named "IHopeItsASafePipe".

  • Prime Mover (unregistered)

    I am so glad I don't have to work with this excrement any more.

  • Argle (unregistered)

    It's interesting to see something like this crop up around the same time I had to deal with it myself. Client had file paths to PDFs in a database. The site was an intranet. Angular just didn't want to let me put the paths on the page to be clicked. I didn't bypass everything (like this example) but just that one local file folder. Worked out ok. I think that was proper use. :-)

  • xtal256 (unregistered)

    It's not just Angular. I remember dealing with this many years back on the hot new JavaScript framework of the day. There would be properties named something like "safeHtml", which didn't ensure that whatever value you gave it was made safe but rather that you were saying it is already safe and therefore no escaping or such should be done on it. Very backwards naming in my opinion.

  • löchleindeluxe (unregistered)

    Ah yes, "leaves safe values safe". How many times have I heard this particular "I swear this time it'll never happen again" (albeit in $otherFramework)?

  • quality_content (unregistered)

    And of course, this originates from Medium.com. When googling this, I found to my horror that I've visited this page before... Looks like today's task is to go through all old projects make sure that a younger, dumber me didn't use this "neat trick" to "secure" anything dangerous!

    https://medium.com/@swarnakishore/angular-safe-pipe-implementation-to-bypass-domsanitizer-stripping-out-content-c1bf0f1cc36b

  • SG (unregistered)

    Yeah. There are definitely situations where disabling escaping is needed... but it's definitely preferable if the function for doing so is called "yesIReallyWantToDisableEscapingBecauseIHaveCheckedThatTheContentIsSafeAndIAmNotAnIdiotWhoCopyPastesCodeLikeThisWithoutUnderstandingWhatIAmDoing()"

  • (nodebb)

    We can pipe if we want to. We can leave your DOMs behind. 'Cause your DOMs don't pipe and if they don't pipe, well, they're no DOMs of mine

  • Bart (unregistered) in reply to Jeremy Pereira

    You're a man without hat?

  • (nodebb)

    Of course, there was an obvious good name for that function: "bypassSecurityTrust" which carries the right weight and also gives a good clue to anyone familiar with the underlying framework.

Leave a comment on “Put Down the Pipe”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article