Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things to Know When Making a Web Application in 2015

blog.venanti.us

Post reply on HN
Print view View original

91–100 of 186 posts

Re: Things to Know When Making a Web Application in 2015

#91

Post by cpitman »

grey-area wrote: post #67
jaawn wrote: post #50

Earlier quoted context omitted.

In general, you may be right, but the security suggestions in this particular post are the same I hear from people "who have experience in security." Also, they often encourage readers to basically go out and find the thing everyone says is the best thing (i.e. "When storing passwords, salt and hash them first, using an existing, widely used crypto library.") I challenge you to point out specific suggestions in this…

There are quite a few misleading or incorrect suggestions, to pick a few: Encryption passwords is not hashing (think this was fixed after publishing due to comments below) OAuth is not for authentication SPA is not suited to all or even most websites, and is far from being 'king' in any sense. CDNs have pros and cons, they don't suit everyone. Localisation does not mean serving assets closer to home, but translating…

Can you explain why OAuth is not for authentication? What does it not do that you expect an authentication system to do? What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?

Re: Things to Know When Making a Web Application in 2015

#92

Post by liviu- »

baddox wrote: post #87
joepie91_ wrote: post #65

Earlier quoted context omitted.

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…

I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.

Re: Things to Know When Making a Web Application in 2015

#93

Post by cpitman »

martin-adams wrote: post #90

>> When users sign up, you should e-mail them with a link that they need to follow to confirm their email I'm curious, why is this good? Sure, sending an email to them so they confirm they have the correct email, but what is the benefit of the verification step? Is it to prevent them from proceeding in case they got the wrong email? It would be nice if this was justified in the article. I would also add, that changin…

This may not be the writer's reason, but I tend to get people's e-mail accidentally. One time someone signed up an iTunes account with my email, then kept requesting new verification emails. Most of these automated emails do not have a "this isn't me" link, since they assume that the person who signed up and the person getting the email are the same.

Re: Things to Know When Making a Web Application in 2015

#94

Post by s_kilk »

martin-adams wrote: post #90

>> When users sign up, you should e-mail them with a link that they need to follow to confirm their email I'm curious, why is this good? Sure, sending an email to them so they confirm they have the correct email, but what is the benefit of the verification step? Is it to prevent them from proceeding in case they got the wrong email? It would be nice if this was justified in the article. I would also add, that changin…

You need to verify that they actually own (or at least have access to) that email address, otherwise all sorts of shenanigans could be had.

Re: Things to Know When Making a Web Application in 2015

#95

Post by paragon_init »

balls187 wrote: post #76
paragon_init wrote: post #66

Earlier quoted context omitted.

If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant. Instead of throwing money at the problem, you can instead choose to teach yourself more about the subject. We maintain a curated list on Github for people interested in learning about application security for this very reason. https://github.com/paragonie/awesome-appse…

> If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant. True. You don't need to hire consultants to perform a security audit. Ask HN and Security Stack Exchange are good free alternatives to get critiques on your approach.

If you build something open source and it gets incredibly popular, security researchers will also probably come to you. This creates its own problems, of course. (Can't have problems without PR.)

Re: Things to Know When Making a Web Application in 2015

#96

Post by cpitman »

woah wrote: post #40
mcdougle wrote: post #13

Earlier quoted context omitted.

I imagine the OP probably meant that and simply wrote the wrong thing in the post. I probably wouldn't have noticed it was the wrong wording if not for this comment chain.

The only acceptable advice in this situation is "use bcrypt". Vague stuff about "hashing or encrypting" is not good enough.

Wait, what about "scrypt"? Maybe the only acceptable advice changed in the last hour? :-)

Re: Things to Know When Making a Web Application in 2015

#97

Post by juliangregorian »

billyhoffman wrote: post #61
vdaniuk wrote: post #44

Earlier quoted context omitted.

Ugh, I will never understand this reasoning. Overheads of fetching library from a CDN are applicable to the first request. Why do you consider this to be an important factor? Also can you provide any stats/citation that cache hit probability on first request is in fact very low?

First, research on hit factor: https://zoompf.com/blog/2010/01/should-you-use-javascript-li... http://statichtml.com/2011/google-ajax-libraries-caching.htm... https://github.com/h5bp/html5-boilerplate/pull/1327#issuecom... I have more recent data on this that is not yet published from my day-to-day work at a web performance company. The pictures has improved somewhat, but not significantly. You are correct, "Overhead…

Come on, man. 5 year old data? 20-30% of top websites are currently using Google's CDN, so it seems like you're wrong about the picture not having improved significantly. You really think people don't have DNS for ajax.googleapis.com already? And HTTPS is available (and default), so you really think somebody is gonna hack Google to serve you bad JS? You also conveniently ignore the benefits of domain sharding and the fact that the CDN will serve the files faster and with lower latency than almost any setup. And that HTTP/2 mitigates the cost of not concatenating your scripts.

Re: Things to Know When Making a Web Application in 2015

#98

Post by dorgo »

tomjen3 wrote: post #81
joepie91_ wrote: post #65

Earlier quoted context omitted.

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

Maybe not all my clients support javascript, but substantially all I care about do. I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it. Works very well.

I enable JS for sites I feel are valueable for me. The first impression is always without JS. If navigation-buttons dont work without JS - I just leave.

Re: Things to Know When Making a Web Application in 2015

#99

Post by grey-area »

cpitman wrote: post #91
grey-area wrote: post #67

Earlier quoted context omitted.

There are quite a few misleading or incorrect suggestions, to pick a few: Encryption passwords is not hashing (think this was fixed after publishing due to comments below) OAuth is not for authentication SPA is not suited to all or even most websites, and is far from being 'king' in any sense. CDNs have pros and cons, they don't suit everyone. Localisation does not mean serving assets closer to home, but translating…

Can you explain why OAuth is not for authentication? What does it not do that you expect an authentication system to do? What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?

People usually use OpenID for that bit and OAuth for the authorisation to use the third party APIs as the customer. There's nothing horribly wrong with third-party signin if it suits you and for smaller projects however it does limit your relationship with customers and tie you in to third party services which might be charged for or shut down at any time, so it's not ideal for many websites. It depends on your requirements.
Post reply on HN