hasOwnProperty. I can understand it, too. First, it takes a lot of writing: compare
if (foo.hasOwnProperty('bar')) to
if (foo.bar). Also, some coders assume that if the object you’re handling is a simple object you created yourself and that you know it has no prototype inheritance, then
hasOwnProperty is useless.
The problem is that
hasOwnProperty is almost always relevant. As in 99% of the cases. So, why not make a habit of always using it? When you don’t, it can really bite you in the ass. Here’s a short story:
The story of a hack
I was helping a friend with his Node.js server. I happened to glance a little piece of code that was basically a cache of valid administration authentication keys. An approximation is:
1 2 3 4 5 6 7 8 9 10 11 12
Seems legit, right? Well, maybe at first glance. But imagine what happens if an attacker passes in a key of
"toString"? BOOM! Yes, it’s that easy to get pwned.
adminCache, like any other object, has a
toString property. I can only imagine how many similar bugs are waiting out there because of this.
Of course, had the line been
if (adminCache.hasOwnProperty(request.getParameter('key'))) everything would have been just fine.
So, please, use
“Maintaining AngularJS feels like Cobol 🤷…”
You want to do AngularJS the right way.
Yet every blog post you see makes it look like your codebase is obsolete. Components? Lifecycle hooks? Controllers are dead?
It would be great to work on a modern codebase again, but who has weeks for a rewrite?
Well, you can get your app back in shape, without pushing back all your deadlines! Imagine, upgrading smoothly along your regular tasks, no longer deep in legacy.
Subscribe and get my free email course with steps for upgrading your AngularJS app to the latest 1.6 safely and without a rewrite.