What things should a programmer implementing the technical details of a Web application consider before making the site Pu Blic? If Jeff Atwood can forget about HttpOnly cookie, sitemaps, and Cross-site request forgeries all in the same Site, what important thing could I is forgetting as well?
I ' m thinking about this from a web developer's perspective, such that someone else is creating the actual design and Conte NT for the site. So while usability and content is more important than the platform, the programmer has little say in. What does need to worry about are that your implementation of the platform are stable, performs well, is secure, and meets Any other business goals (like not cost too much, take too long to build, and rank as well with Google as the content Sup Ports).
Think of the perspective of a developer who's done some work for intranet-type applications in a fairly trusted Environment, and is on to has his first shot and putting out a potentially popular site for the entire big bad world W IDE web.
Also, I ' m looking for something more specific than just a vague "web standards" response. I mean, HTML, JavaScript, and CSS over HTTP is pretty much a given, especially when I ' ve already specified so you ' re a Professional web Developer. So going beyond that, which standards? What is circumstances, and why? provide a link to the standard ' s specification.
The idea here is, the most of us should already know, the most of the. But there just might be one or both items you haven ' t really looked into before, don ' t fully understand, or maybe never eve N heard of.
Interface and User Experience
- Be aware this browsers implement standards inconsistently and make sure your site works reasonably well across all major B Rowsers. At a minimum test against a recent Gecko engine (Firefox), a WebKit engine (Safari and some mobile browsers), Chrome, your Supported IE browsers (take advantage of the application Compatibility VPC Images), and Opera. Also consider how browsers render your site in different operating systems.
- Consider how people might use the site other than from the major Browsers:cell phones, screen readers and search engines, For example. -some accessibility Info:wai and Section508, Mobile Development:mobiforge.
- Staging:how to deploy updates without affecting your users. has one or more test or staging environments available to implement changes to architecture, code or sweeping content and Ensure that they can is deployed in a controlled to without breaking anything. has an automated-on-the-then deploying approved changes to the live site. This is the most effectively implemented in conjunction with the use of a version control system (CVS, Subversion, etc) and a n Automated build mechanism (ANT, NAnt, etc.).
- Don ' t display unfriendly errors directly to the user.
- Don ' t put users ' email addresses in plain text as they'll get spammed to death.
- Add the attribute to
rel="nofollow" user-generated links to avoid spam.
- Build well-considered limits into your site-this also belongs under Security.
- Learn how to do progressive enhancement.
- Redirect after a post if that POST is successful, to prevent a refresh from submitting again.
- Don ' t forget to take accessibility into account. It's always a good idea and in certain circumstances it ' s a legal requirement. Wai-aria and WCAG 2 is good resources in the area.
- Don ' t make me think
Security
- It's a lot to digest and the OWASP Development Guide covers Web Site security from top to bottom.
- Know about injection especially SQL injection and what to prevent it.
- Never trust user input, nor anything else, comes in the request (which includes cookies and hidden form field values!) .
- Hash passwords using salt and use different salts for your rows to prevent rainbow attacks. Use a slow hashing algorithm, such as Bcrypt (time tested) or scrypt (even stronger, but newer) (1, 2), for storing passwo Rds. (How to safely Store A Password). The NIST also approves of PBKDF2 to hash passwords ", and it's FIPS approved in. NET (more info here). Avoid using MD5 or SHA family directly.
- Don ' t try to come up with your own fancy authentication system. It ' s such an easy thing-get wrong in subtle and untestable ways and you wouldn ' t even know it until after you ' Re hacked.
- Know the rules for processing credits cards. (see this question as well)
- Use Ssl/https for login and any pages where sensitive data is entered (like credit card info).
- Prevent session hijacking.
- Avoid Cross Site scripting (XSS).
- Avoid Cross Site Request forgeries (CSRF).
- Avoid Clickjacking.
- Keep your system (s) up to date with the latest patches.
- Make sure your database connection information is secured.
- Keep yourself informed about the latest attack techniques and vulnerabilities affecting your platform.
- Read the Google Browser Security Handbook.
- Read the Web application Hacker ' s handbook.
- Consider the principal of least privilege. Try to run your app server as Non-root. (Tomcat example)
Performance
- Implement caching if necessary, understand and use HTTP caching properly as well as HTML5 Manifest.
- Optimize Images-don ' t use a-KB image for a repeating background.
- Learn how to gzip/deflate content (deflate is better).
- Combine/concatenate multiple stylesheets or multiple script files to reduce number of browser connections and improve gzip Ability to compress duplications between files.
- Take a look at the Yahoo exceptional performance site, lots of great guidelines, including improving front-end performance and their YSlow tool (requires Firefox, Safari, Chrome or Opera). Also, Google page speed (with the use of browser extension) is the another tool for performance profiling, and it optimizes your imag Es too.
- Use CSS Image Sprites to small related images like toolbars (see the "Minimize HTTP requests" point)
- BUSY Web sites should consider splitting components across domains. specifically ...
- Static content (i.e. images, CSS, JavaScript, and generally content that doesn ' t need access to cookie) should go in a SE Parate domain that does don't use cookies, because all cookie for a domain and its subdomains is sent with every Request to the domain and its subdomains. One good option, here are to use a Content Delivery Network (CDN).
- Minimize the total number of HTTP requests required for a browser to render the page.
- Utilize Google Closure Compiler for JavaScript and other minification tools.
- Make sure there's a
favicon.ico file in the root of the site, i.e. /favicon.ico Browsers would automatically request it, even if the icon isn ' t mentioned in the HTML at all. If You don has a, this would /favicon.ico result in a lot of 404s, draining your server's bandwidth.
SEO (Search Engine optimization)
- Use the "search engine friendly" URLs, i.e. use
example.com/pages/45-article-title instead ofexample.com/index.php?page=45
- When a using for dynamic content change the and then on the the server is what
# # #! $_REQUEST["_escaped_fragment_"] Googlebot uses instead of #! . In other words, ./#!page=1 becomes ./?_escaped_fragments_=page=1 . Also, for users, the May are using FF.B4 or Chromium, is history.pushState({"foo":"bar"}, "About", "./?page=1"); a great command. So even though the address bar have changed the page does not reload. This allows-instead of ? #! keep dynamic content and also tell the server when you email the link t Hat we is after this page, and the AJAX does not need to make another extra request.
- Don ' t use links to this say "click here". You ' re wasting a SEO opportunity and it makes things harder for people with screen readers.
- Has an XML sitemaps, preferably in the default location
/sitemap.xml .
- Use if you have
<link rel="canonical" ... /> multiple URLs, the same content, this issue can also is addressed from Google Webmast Er Tools.
- Use Google Webmaster tools and Bing Webmaster tools.
- Install Google Analytics right at the start (or a Open source analysis tool like Piwik).
- Know how robots.txt and search engine spiders work.
- Redirect requests (using
301 Moved Permanently ) asking for www.example.com example.com (or the other-round) to prevent splitting the Google ranking between both sites.
- Know that there can is badly-behaved spiders out there.
- If you had non-text content look into Google's sitemap extensions for video etc. There is some good information on this in Tim Farley ' s answer.
Technology
- Understand HTTP and things like GET, POST, sessions, Cookie, and what it means to be "stateless".
- Write your xhtml/html and CSS according to the website specifications and make sure they validate. The goal here's to avoid browser quirks modes and as a bonus make it much easier to work with non-standard browsers like Screen readers and mobile devices.
- Understand how JavaScript was processed in the browser.
- Understand how JavaScript, style sheets, and other resources used by your page is loaded and consider their impact on perceived performance. It's now widely regarded as appropriate to move scripts to the bottom of your pages with exceptions typically being thing s like analytics apps or HTML5 shims.
- Understand how the JavaScript sandbox works, especially if you intend to use IFRAMEs.
- Be aware that JavaScript can and would be disabled, and that AJAX was therefore an extension, not a baseline. Even if most normal users leave it in now, remember that NoScript are becoming more popular, mobile devices Expected, and Google won ' t run most of the your JavaScript when indexing the site.
- Learn the difference between 301 and 302 redirects (this was also an SEO issue).
- Learn as much as you possibly can about your deployment platform.
- Consider using a Reset Style Sheet or NORMALIZE.CSS.
- Consider JavaScript frameworks (such as JQuery, MooTools, Prototype, Dojo or YUI 3), which would hide a lot of the browser Differences when using a JavaScript for DOM manipulation.
- Taking perceived performance and JS frameworks together, consider using a service such as the Google Libraries API to load Frameworks so, browser can use a copy of the framework it has already cached rather than downloading a duplicate co Py from your site.
- Don ' t reinvent the wheel. Before doing anything search for a component or example on how to do it. There is a 99% chance that someone have done it and released an OSS version of the code.
- On the flipside of this, don ' t start with a libraries before you ' ve even decided what your needs is. Particularly on the Client-side web where it's almost always ultimately more important to keep things lightweight, fast, a nd flexible.
Bug Fixing
- Understand you ' ll spend 20% of your time coding and 80% of it maintaining, so code accordingly.
- Set up a good error reporting solution.
- There is a system for people-to-contact, with suggestions and criticisms.
- Document How the application works for future support staff and people performing maintenance.
- Make frequent backups! (and make sure those backups is functional) Ed Lucas ' s answer has some advice. There is a restore strategy, not just a backup strategy.
- Use a version control system to store your files, such as Subversion, Mercurial or Git.
- Don ' t forget to do your acceptance testing. Frameworks like Selenium can help.
- Make sure are sufficient logging in place using frameworks such as log4j, log4net or log4r. If something goes wrong on the your live site, you'll be need a by the finding out.
- When logging make sure you capture both handled exceptions, and unhandled exceptions. Report/analyse the log output, as it ' ll show you where the key issues is in your site.
Lots of stuff omitted not necessarily because they ' re not useful answers, but because they ' re either too detailed, out of Scope, or go a bit too far-someone looking to get a overview of the things they should know. Please feel the free-to-edit this as well, I probably missed some stuff or made some mistakes.
source: http://programmers.stackexchange.com/questions/46716/ What-technical-details-should-a-programmer-of-a-web-application-consider-before
