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"
Things to Know When Making a Web Application in 2015
51–60 of 186 posts
Re: Things to Know When Making a Web Application in 2015
#52Earlier quoted context omitted.
Look up "medium-brow dismissal"
I did. Wasn't sure what I was looking for. 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.
(edit: this is an explanation of what "middle-brow dismissal" is)
Re: Things to Know When Making a Web Application in 2015
#53Earlier quoted context omitted.
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 the same in everything. I'd say passwords are "encrypted" in my systems (even though they're salted/hashed). 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.
Re: Things to Know When Making a Web Application in 2015
#54I don't know much about web development, but shouldn't those resources get cached? Isn't the disadvantage of SPAs that you are unable to link to / share a specific piece of content?
Re: Things to Know When Making a Web Application in 2015
#55If 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 wouldnt take any advice on web dev from someone if his simple blog looks like this http://i.imgur.com/uHi0g0Z.png brb compiling linux to JS to render my blog post.
Re: Things to Know When Making a Web Application in 2015
#56If 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…
It is easy to write that, and on the face of it, it's hard to argue against.
The trouble is, those audits and consultants don't come cheap, and if you're new at web apps and working on your first one that no-one has ever heard of yet, there is little really essential that you wouldn't find investing the same time reading the usual beginners' guides to security on-line. It's all risk management, and if you even make that effort you'll already be a significantly harder target than many established sites.
As a corporate lawyer once told me when I was getting the very first contract drawn up for a new business, for a simple supplier relationship, he could certainly charge me five figures and write an extensive document protecting the business against every conceivable threat he could imagine involving that supplier, but until the business had actual revenues worth protecting and the deal with that particular supplier was worth a lot more than the legal fees, he wouldn't advise doing it.
Re: Things to Know When Making a Web Application in 2015
#57First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance. > If you're just starting out with a new web application, it should probably be an SPA. Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity. In ne…
If you're just starting out, chances are you are not (or should not be) making any sort of application where the performance increases by operating as a SPA will be even be noticeable compared to a standard server app.
Plus, I'd argue that you won't really understand what a SPA adds (or takes away) unless you are thoroughly familiar with the traditional model.
Finally, at the end of the day traditional apps are just a lot easier to put together even compared to the latest SPA frameworks, especially if your server side tech is something like Ruby or C#. A beginner will be better served by getting something nice up quickly, before attempting to do it the 'purist' way and possibly getting discouraged by the difficulty.
Re: Things to Know When Making a Web Application in 2015
#58heres a compressed version: https://www.dropbox.com/s/bw606t7znouxpj1/photo-141847963101...
Re: Things to Know When Making a Web Application in 2015
#59>When storing passwords, encrypt them Nopenopenopenopenope! This is terrible advice. Don't do this. Remember what happened when Adobe did this?
Re: Things to Know When Making a Web Application in 2015
#60> The key advantage to an SPA is fewer full page loads - you only load resources as you need them, and you don't re-load the same resources over and over. I don't know much about web development, but shouldn't those resources get cached? Isn't the disadvantage of SPAs that you are unable to link to / share a specific piece of content?
server side yes, what he means is that you only need to load the content as a client now, not the layout.
> Isn't the disadvantage of SPAs that you are unable to link to / share a specific piece of content?
If it's well done no, since you can dynamically update the URL with javascript.