14 ms·
Things to Know When Making a Web Application in 2015
- balls187 11y ago> If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. OAuth isn't identity management, it's for authorization. Each of those platforms does provide it's own identity management, but that isn't OAuth.
- ad-hominem 11y agoI think he may have confused OAuth with OpenID (which are often used in a complementary fashion).
- artmageddon 11y agoI took that to mean use both identity management as well as OAuth.
- balls187 11y ago1. Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? 2. Security best practices subject to "open for interpretation."
- superuser2 11y agoWhile OAuth isn't "for" authentication, everyone uses it that way by "authorizing" access to "view your email address" which is as good as authenticating your email address.
- balls187 11y agoCan you link to implementations that use OAuth in such a manner? Login with FB, Google, Github, Twitter, etc different systems, separate from OAuth.
- cpitman 11y agoGitHub How To: https://developer.github.com/guides/basics-of-authentication/ https://developer.github.com/guides/basics-of-authentication... And the OpenID Connect standard (essentially OAuth V2 + identity service): http://openid.net/connect/ http://openid.net/connect/
- hello_there 11y ago> Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? So, what would you use instead?
- avinassh 11y ago> Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? Can you explain me this? How Google will be able to access my service data?
- lewisl9029 11y agoThe OAuth based OpenID Connect is for identity management. http://openid.net/connect/ http://openid.net/connect/ Personally, I still prefer Persona's privacy-oriented approach to id management, but since Mozilla stopped pushing it, development has slowed quite a bit and widespread adoption will probably never happen. https://www.mozilla.org/en-US/persona/ https://www.mozilla.org/en-US/persona/
- shiggerino 11y ago>When storing passwords, encrypt them Nopenopenopenopenope! This is terrible advice. Don't do this. Remember what happened when Adobe did this?
- rfrey 11y agoThe full quote is: "When storing passwords, encrypt them first, using an existing, widely used crypto library. If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow." Can you elaborate on what's so "nope" about that advice? Are you saying one shouldn't encrypt passwords?
- atwebb 11y agoI think they're assuming it can be decrypted instead of one-way.
- ad-hominem 11y agoEncryption means encrypting information which can later be decrypted. If you are talking about a one-way transform of data that you can never retrieve the original information from the result of the transformation, that is called hashing. We hash passwords, not encrypt them.
- smt88 11y agoEncryption isn't encryption if it's one-way.
- atwebb 11y agoThanks, I was trying to rephrase it, similar to people using IM in this thread but being off-base with it's actual meaning.
- ovi256 11y agoOf course one shouldn't encrypt them, one should salt and hash them. With a cryptographically secure hash such as bcrypt or scrypt. If you use a batteries-included web-framework, this is already done for you. If you do not, you better understand the tradeoff of redeveloping those parts.
- patcheudor 11y agoFor mobile apps that use WebView and/or has the capability to execute javascript or any other language provided by any network available resource I'd like to add: ALWAYS USE CRYPTOGRAPHY for communication! Simply doing HTTP to HTTPS redirects is not sufficient. The origin request must be via HTTPS. Also make sure the app is properly validating the HTTPS connection. Sorry I had to shout, but I'm growing tired of downloading the latest cool app that is marketed as secure only to find that it doesn't use HTTPS and as a result I can hijack the application UI to ask users for things like their password, credit-card number, etc., all without them having any way to tell if they are being asked by some bad guy.
- jawshie 11y ago>Confirm emails: When users sign up, you should e-mail them with a link that they need to follow to confirm their email. And I think this should be the only verification done for email addresses aside from very basic structure. It is highly frustrating signing up for a service that does not allow address aliases (eg myemail+hackernews@gmail.com) because they don't think '+' belongs in an email address. I am already validating my address for you! Don't lose me as a customer because I don't trust you won't spam me. >Encryption: For all of its problems with certificates, there's still nothing better than SSL. SSL is deprecated. Use TLS. And for the love of god, don't autoplay audio. There is no faster way for me to close your tab and never go to your site again.
- andersonmvd 11y agoWhen using SPA, validate CORS origin instead of allowing *.
- balls187 11y agoIf 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 single blog post/article is going to distill the nuances down in an easy to digest manner.
- codingdave 11y agoSecurity 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.
- balls187 11y ago> 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-management-hackers-got-data-of-millions.html http://www.nytimes.com/2015/07/10/us/office-of-personnel-man...
- woah 11y agoLook up "medium-brow dismissal"
- balls187 11y agoI did. Wasn't sure what I was looking for. https://www.google.com/search?q=medium-brow+dismissal&ie=utf-8&oe=utf-8 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.
- jameshart 11y ago"You don't have to develop for mobile..." ... well, no. Technically you don't have to. But you almost certainly should.
- davnicwil 11y agoWas 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'
- trace303 11y agoYes, even moreso now since it hurts your Google page rank to not make your app mobile friendly.
- jameshart 11y agoI believe it only hurts your google rank for searches conducted on a mobile device. So, most searches, then.
- jmulho 11y agoIn 2015, my primary use of web apps "for mobile" is to find the link that says "full site".
- davnicwil 11y agoThat's exactly why the inverted advice needs to be heeded, so that that sucky experience, which does still occur daily with a lot of sites and apps, goes away by default. Note, I'm absolutely not saying that a big screen desktop experience isn't inherently better for all but the simplest apps, there's very high probability it is because it's more ergonomic hardware with far more screen real estate. However since most people want to, and do use mobile in preference to desktop for a huge proportion of tasks now, the design philosophy in most cases needs to flip from 'full functionality for desktop, scale down gracefully for mobile' to 'full functionality for mobile, scale up for desktop, taking advantage of the extra UX potential where possible'. It's actually a far more optimistic, and creative, approach. Make it, then enhance it for the less popular use case rather than make it, then degrade it for the less popular use case.
- romaniv 11y ago> All assets - Use a CDN > If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. Questionable advice. At the very least neither of these two are some kind of automatic "best practice" everyone should just follow. > it can be helpful to rename all those user.email vars to u.e to reduce your file size Or maybe you should less JavaScript so length of your variable names does not matter.
- deleted 11y ago[deleted]
- Yhippa 11y agoI like this list. > Forms: When submitting a form, the user should receive some feedback on the submission. If submitting doesn't send the user to a different page, there should be a popup or alert of some sort that lets them know if the submission succeeded or failed. I signed up for an Oracle MOOC the other day and got an obscure "ORA-XXXXX" error and had no idea if I should do anything or if my form submission worked. My suggestion would be to chaos monkey your forms because it seems that whatever can go wrong can. Make it so that even if there is an error the user is informed of what is going on and if there's something they can do about it.
- vbezhenar 11y agoOne thing to note is login redirect. Please be sure that redirect parameter is local URI and don't redirect user to another site. Maybe even append HMAC signature to that parameter with user IP and timestamp. Might be an overkill, but still be careful with craftable redirects, they might become vulnerability one day.
- rudolf0 11y agoTrue, open redirects can cause serious security issues. Do not have an route that simply does the equivalent of `return redirect(params["url"])`, either at login or anywhere.
- devNoise 11y agoQuestion 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 more HTTP requests, which sometimes takes more time to request than to download the library. I agree that using CDNs is a good speed boost. I'm trying to figure out if hoping for a library cache hit out weights a library cache miss.
- mbq 11y agoAlso pulling anything from CDN basically means that CDN operator (or anyone that will manage to hack it) can spy on or alter communication between your users and your server.
- billyhoffman 11y agoJust 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 that, if everyone references the same copy of jQuery on one of these shared hosts, the when visitors hit other sites, jQuery will already be in their browser cache. This rarely works in practice. The URLs to these shared libraries. Multiple shared services. Multiple version numbers. HTTPS vs HTTP. The net result is that the probability that someone visiting your site has a copy of the exactly same resource referenced via the exact same URL is very low. With the overhead of having to do a DNS lookup, a TCP connection, TCP slow start, its rarely worth it. Just concat/minify into your own block of JS served from your own systems. Shared JS hosts/CDNs are a terrible and annoying hack, all in an attempt to save 50KB or so
- vdaniuk 11y agoUgh, 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?
- tspike 11y agoFirst 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 nearly every case where an existing app I know and love transitions to a single-page app (seemingly just for the sake of transitioning to a single-page app), performance and usability have suffered. For example, I cannot comprehend why Reddit chose a single-page app for their new mobile site. It's a lot harder to get a single-page app right than a traditional app which uses all the usability advantages baked in to the standard web.
- AdeptusAquinas 11y agoThis is totally true. 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.
- deleted 11y ago[deleted]
- joepie91_ 11y agoI fully agree with this. SPAs are for webapps, not websites. 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 need to, for a website.
- Domenic_S 11y agoHow to make a reasonbly-decent webapp in 2015 without having to worry about bcrypt and open redirects and such: 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.
- ahayschi 11y agoI think this is more of a question of what kind of project or team you are working on, not one of experience in web development. Because it seems that you're suggesting beginners use Sails or Meteor (if focusing on JS), which are great and allow for rapid prototyping, but they and other 'high-level frameworks' that implement these methods for you tend to be very opinionated with important details of developing for the web abstracted away. If you're a student or are serious about learning web development (and want to focus on developing in JS), it would make a lot of sense to dedicate your time to actually learning Node and Express, figuring out all of these hairy details and 'manually' implementing the items in Venantius' list. Or don't figure out the hairy details, because many of his items have proven and documented solutions in the Node context, and learning how to properly use bcrypt and passport isn't too difficult. These libs are a good middle-ground between low-level details and something more out of the box.
- toynbert 11y agoAs a web application developer in 2015+ I would argue that developing with mobile in mind should be required. At least taken into consideration. At bare minimum have a pre-deployment test: is my app unusable/does this look terrible on the most popular iphone/android.
- schnable 11y agoAnd that it passes Google's mobile check, so it doesn't get penalized in SERPs.
- Quanttek 11y ago> 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?
- baby 11y ago> but shouldn't those resources get cached? 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.
- blowski 11y ago> Isn't the disadvantage of SPAs that you are unable to link to / share a specific piece of content? Actually, this is achievable with push states, so isn't a strong argument against single page apps. I think the problem with SPAs is that they exacerbate memory leaks, since they don't have the typical 'reset' of a browser page load to clear them. Also, a lot of SPAs re-implement browser functionality like scrollbars and the back button without proper cross-browser testing - let alone usability testing. Conceptually, there's nothing wrong with SPAs, but many of the implementations are shoddy at best with no clear advantage gained.
- quadrature 11y agoThis is a bit of a pet peeve of mine, but that banner image is 10 megabytes, it can be compressed down to 2mb without any perceptible loss of quality. Heck it could probably be shrunk further if you can accept a bit more loss because most of the image is blurry and noisy anyway. heres a compressed version: https://www.dropbox.com/s/bw606t7znouxpj1/photo-1418479631014-8cbf89db3431_mini.jpeg?dl=0 https://www.dropbox.com/s/bw606t7znouxpj1/photo-141847963101...
- cpeterso 11y agoIronically the original banner image doesn't even load for me on iOS Safari.
- exodust 11y ago10 meg? 4k is all the rage now on mobile. just taken a chunk out of someone's download quota with that nice background!
- quadrature 11y agoI've been thinking of developing a proxy that compresses responses and forwards them to you, specifically to handle sites not optimized for mobile. There are already solutions like this but I think a self hosted version is what people need.
- A_COMPUTER 11y agoThis one has been around a long time: http://www.khelekore.org/rabbit/ http://www.khelekore.org/rabbit/
- quadrature 11y agothanks!, That will definitely help a lot. I was thinking of using squid proxy and writing some custom handlers, but this helps a lot.
- lewisl9029 11y ago
- sarciszewski 11y ago>For all of its problems with certificates, there's still nothing better than SSL. Yes there is. It's called Transport Layer Security (TLS).
- deleted 11y ago[deleted]
- donmb 11y agoRails has most of this out of the box. Use Rails :)
- avinassh 11y agoI think, even Django also has most of this stuff.
- anton_gogolev 11y ago> sent to a page where they can log in, and after that should be redirected to the page they were originally trying to access (assuming, of course, that they're authorized to do so). Smells like an information discolsure highway. I usually 404 all requests that hit "unauthorized" content.
- martin-adams 11y ago>> 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 changing a password should send an email to the account holder to notify them. Then when changing the email address, the old email address should be notified. This is so a hijacked account can be detected by the account owner.
- cpitman 11y agoThis 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.
- s_kilk 11y agoYou need to verify that they actually own (or at least have access to) that email address, otherwise all sorts of shenanigans could be had.
- nly 11y agoPrimarily, verified email is the way everyone does password resets.
- deleted 11y ago[deleted]
- Kudos 11y agoOne big omission from this list: gzip. Before you ever think about uglify, make sure you're gzipping your textual assets.
- stevewilhelm 11y agoInternationalization?
- joepie91_ 11y ago> If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. The thing that everybody seems to overlook here: this has serious legal consequences. You are demanding of your users that they agree to a set of TOS from a third party, that does not have either their or your best interests at heart, and that could have rather disturbing things in their TOS - such as permission to track you using widgets on third-party sites. Not to mention the inability to remove an account with a third-party service without breaking their authentication to your site as well. Always, always offer an independent login method as well - whether it be username/password, a provider-independent key authentication solution, or anything else. > When storing passwords, salt and hash them first, using an existing, widely used crypto library. "Widely used" in and of itself is a poor metric. Use scrypt or bcrypt. The latter has a 72 character input limit, which is a problem for some passphrases, as anything after 72 characters is silently truncated.
- JikkuJose 11y agoHey uncss supports dynamically added stylesheets too (via running in through PhantomJS).
- Kiro 11y ago> Avoid lazy transition calculations, and if you must use them, be sure to use specific properties (e.g., "transition: opacity 250ms ease-in" as opposed to "transition: all 250ms ease-in") Why is it better to be specific?
- Kiro 11y ago> Confirm emails Why?
- y_mesh 11y agoIt's for authentication. It's kinda like: you (email server) know this person, then we (developer) know this person.
- sashasklar 11y agoThe author mentions he uses grunt for ui build/optimization without caveating that it hasn't seen a release in over a year: https://github.com/gruntjs/grunt/releases https://github.com/gruntjs/grunt/releases. The project team has gone radio silent and even the mainline "contrib" plugins have unanswered issues and pull requests. TL;DR If you are starting a new project, don't use grunt.
- sambeau 11y agoI was surprised at the lack of mention of SVG. The biggest change to my working habits (apart for working in a SPA) is that every non-photographic image I use is now SVG.
- lewisl9029 11y agoDon't be surprised. See this: https://news.ycombinator.com/item?id=9866461 https://news.ycombinator.com/item?id=9866461
- suyashbansal 11y agoI was thinking to make a web app for my college project. Can you please help me with some inspirations for my project ? :P
- jgalt212 11y ago>If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. Has anyone built a lasting stand-alone business that relies on Facebook, et al for identity management?
- tim333 11y agoTinder? Facebook only when I tried. Valued > 1 $bn http://www.businessinsider.com/jmp-securities-analyst-note-on-tinder-2015-4 http://www.businessinsider.com/jmp-securities-analyst-note-o...
- tomcam 11y agoweb2py is a batteries-included framework that has all of this and much more done for you, tested and proven over many years.
- leezk 11y agoThank u very much! The article is very useful for me, I translated it into Chinese. here http://codecloud.net/2015-web-app-4932.html http://codecloud.net/2015-web-app-4932.html