41–50 of 186 posts
1. Use a widely-accepted framework.
2. Implement your application using that framework's methods.
Why a beginner would implement even 1/3 of this list manually is beyond me.
Question about JavaScript and CDN for mobile devices. Should I use a CDN for standard libraries or should I just concat and minify all my JavaScript? The concat and minify seems better as that reduces the JavaScript libraries and code load to a single HTTP request. A CDN seems nice in theory. Reality is: Does the browser have the library cached? Is the library cached from the CDN that I'm using? The browser is making…
jQuery CDN has something like 99,8% cache hits. And even if the browser doesn't have the library cached, it will have it cached on all subsequent request. Additional roundtrips will be needed on first page load only. Take into consideration that as soon as you make even a small change to your js files, the whole minified and bundled JavaScript will need to be redownloaded.
Earlier quoted context omitted.
Was surprised to see this too, considering the article's title is Things to Know When Making a Web Application in 2015 If anything the advice should be inverted by replacing 'mobile' with 'desktop'
Yes, even moreso now since it hurts your Google page rank to not make your app mobile friendly.
So, most searches, then.
Question about JavaScript and CDN for mobile devices. Should I use a CDN for standard libraries or should I just concat and minify all my JavaScript? The concat and minify seems better as that reduces the JavaScript libraries and code load to a single HTTP request. A CDN seems nice in theory. Reality is: Does the browser have the library cached? Is the library cached from the CDN that I'm using? The browser is making…
Just to clarify. General CDNs tend to be a good idea of you are having latency issues. Standard libraries for major JavaScript project, all served from a single shared CDN (like Google, maxcdn, cdnjs, etc) also tend to be called "CDNs" but this is a little confusing. Yes, these shared files are often stored on a CDN, but that's not the so-called major benefit of these shared hosts. The main benefit is supposed to be…
Also can you provide any stats/citation that cache hit probability on first request is in fact very low?
Earlier quoted context omitted.
Which raises the question: should you follow web application advice regarding security from someone who mistakenly uses the word "Encrypt" when they (actually or unintentially) mean "Hash?"
Yeah, yeah, I think I would. Someone's credibility as a programmer isn't destroyed in my mind because they say encrypt to describe hashing, especially if they are in fact, hashing and not encrypting and understand why. This is something I've seen a lot of developers act elitist about, and it's always rubbed me the wrong way.
It's like the gun nuts that flip out when someone calls it an assault rifle or a clip instead of a magazine.
What can you do, people like showing off how "smart" they are.
If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…
Earlier quoted context omitted.
> So why not just accept the post for what it is - some basic advice to do that one better step. http://www.nytimes.com/2015/07/10/us/office-of-personnel-man...
Look up "medium-brow dismissal"
https://www.google.com/search?q=medium-brow+dismissal&ie=utf...
It's clearly a logical failure to suggest heeding the authors advice would result in a catastrophic security breach.
Not paying attention to security by reason of "I've done a little better than nothing at all" feels like willful negligence.
Earlier quoted context omitted.
Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.
If you're going to do something, do it right. Security is never perfect, and to security people, we know that there is a tradeoff between Security and Users. We don't advocate letting The Perfect be the Enemy of the Good when it comes to security, and on the same token we want you to implement security properly if you do it.
If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…
I challenge you to point out specific suggestions in this article which are wrong or misleading, or to point out glaring omissions.