在将网站公开之前，Web 应用程序的程序员应该考虑哪些技术细节？

Posted 2023-02-24

【中文标题】在将网站公开之前，Web 应用程序的程序员应该考虑哪些技术细节？

【英文标题】：What technical details should a programmer of a web application consider before making the site public?

【发布时间】：2010-09-09 12:00:17

【问题描述】：

在将网站公开之前，实现 Web 应用程序技术细节的程序员应该考虑哪些事项？如果Jeff Atwood 可以忘记HttpOnly cookies、sitemaps、和cross-site request forgeries都在同一个站点，我还能忘记什么重要的事情？

我从网络开发人员的角度考虑这个问题，这样其他人正在为网站创建实际的设计和内容。因此，虽然可用性和内容可能比平台更重要，但程序员在这方面几乎没有发言权。您需要担心的是您的平台实现是稳定的、性能良好的、安全的，并且满足任何其他业务目标（例如成本不高、构建时间过长以及在 Google 中的排名与内容支持）。

从开发人员的角度来考虑这一点，他在相当受信任的环境中为 Intranet 类型的应用程序完成了一些工作，并且即将开始他的第一次尝试，并为整个大型糟糕的万维网推出一个可能受欢迎的网站.

另外，我正在寻找比模糊的“网络标准”响应更具体的东西。我的意思是，HTTP 上的 html、javascript 和 CSS 几乎是给定的，尤其是当我已经指定您是专业的 Web 开发人员时。那么除此之外，哪些标准？在什么情况下，为什么？ 提供标准规范的链接。

【参考方案1】：

这里的想法是，我们大多数人应该已经知道大部分列表中的内容。但可能只有一两个项目你以前没有真正研究过，不完全理解，或者甚至可能从未听说过。

界面和用户体验

请注意，浏览器执行标准的方式不一致，并确保您的网站在所有主要浏览器中都能正常运行。至少针对最近的Gecko 引擎（Firefox）、WebKit 引擎（Safari 和一些移动浏览器）、Chrome、您支持的IE browsers（利用Application Compatibility VPC Images）进行测试，以及Opera。还要考虑browsers render your site 在不同操作系统中的作用。 考虑除了主要浏览器之外，人们如何使用该网站：例如，手机、屏幕阅读器和搜索引擎。 — 一些可访问性信息：WAI 和 Section508，移动开发：MobiForge。 暂存：如何在不影响用户的情况下部署更新。拥有一个或多个测试或暂存环境来实施对架构、代码或全面内容的更改，并确保它们可以以受控方式部署而不会破坏任何内容。有一种自动化的方式，然后将批准的更改部署到实时站点。结合使用版本控制系统（git、Subversion 等）和自动构建机制（Ant、NAnt 等），可以最有效地实现这一点。 不要直接向用户显示不友好的错误。 不要将用户的电子邮件地址以纯文本形式显示，否则他们会被垃圾邮件致死。 将属性rel="nofollow" 添加到用户生成的链接to avoid spam。 Build well-considered limits into your site - 这也属于安全性。 了解如何操作progressive enhancement。 Redirect after a POST 如果 POST 成功，防止再次提交刷新。 不要忘记考虑可访问性。这总是一个好主意，在某些情况下它是legal requirement。 WAI-ARIA 和 WCAG 2 是这方面的好资源。 阅读Don't Make Me Think。

安全

要消化的内容很多，但 OWASP development guide 涵盖了从上到下的网站安全性。 了解注射，尤其是SQL injection 以及如何预防。 永远不要相信用户输入，也不要相信请求中的任何其他内容（包括 cookie 和隐藏的表单字段值！）。 使用salt 对密码进行哈希处理，并为您的行使用不同的盐以防止彩虹攻击。使用慢散列算法，例如 bcrypt（经过时间考验）或 scrypt（更强大，但更新）（1，2）来存储密码。 (How To Safely Store A Password)。 NIST also approves of PBKDF2 to hash passwords"，它是 FIPS approved in .NET（更多信息 here）。避免直接使用 MD5 或 SHA 系列。 Don't try to come up with your own fancy authentication system。以微妙且无法测试的方式出错是一件很容易的事情，直到你被黑客入侵之后你才知道。 知道rules for processing credit cards。 (See this question as well) 将SSL/TLS/HTTPS 用于输入敏感数据（如凭据、个人身份信息、信用卡信息）的任何站点。 Let's Encrypt 是一个免费的证书颁发机构，可以提供帮助。 Prevent session hijacking. 避免cross site scripting (XSS)。 避免cross site request forgeries (CSRF)。 避免Clickjacking。 使用最新补丁使您的系统保持最新状态。 确保您的数据库连接信息是安全的。 随时了解影响您平台的最新攻击技术和漏洞。 阅读The Google Browser Security Handbook。 阅读The Web Application Hacker's Handbook。 考虑The principle of least privilege。尝试运行您的应用服务器as non-root。 (tomcat example) 在所有用户提供的链接上加上rel="noopener noreferrer"target="_blank"，以防止目标页面上的JavaScript 将您的页面重定向到其他地方，例如虚假登录页面。 More Info 考虑使用strict Content Security Policy。

性能

必要时实施缓存，正确理解和使用HTTP caching以及HTML5 Manifest。 优化图片 - 不要使用 20 KB 的图片作为重复背景。 压缩内容以提高速度，请参阅brotli、gzip/deflate (deflate is better)。 组合/连接多个样式表或多个脚本文件，以减少浏览器连接数并提高 gzip 压缩文件之间重复项的能力。 看看Yahoo Exceptional Performance 站点，其中有很多很棒的指南，包括提高前端性能和他们的YSlow 工具（需要Firefox、Safari、Chrome 或Opera）。此外，Google page speed（与browser extension 一起使用）是另一种性能分析工具，它也可以优化您的图像。 将CSS Image Sprites 用于工具栏等小型相关图像（请参阅“最小化 HTTP 请求”点） 将SVG image sprites 用于工具栏等小型相关图像。 SVG 着色有点棘手。你可以阅读它here。 繁忙的网站应该考虑splitting components across domains。具体... 静态内容（即图像、CSS、JavaScript 和通常不需要访问 cookie 的内容）应该放在单独的域中that does not use cookies，因为域的所有 cookie 及其子域与对域及其子域的每个请求一起发送。一个不错的选择是使用内容交付网络 (CDN)，但考虑到 CDN 可能会因包含替代 CDN 或可以提供的本地副​​本而失败的情况。 尽量减少浏览器呈现页面所需的 HTTP 请求总数。 选择一个 template engine 并使用 gulp 或 grunt 等任务运行器渲染/预编译它 确保站点根目录中有favicon.ico 文件，即/favicon.ico。 Browsers will automatically request it，即使 HTML 中根本没有提到该图标。如果您没有/favicon.ico，这将导致大量 404，耗尽您的服务器带宽。

SEO（搜索引擎优化）

使用“搜索引擎友好”的 URL，即使用 example.com/pages/45-article-title 而不是 example.com/index.php?page=45 当使用# 动态内容时，将# 更改为#!，然后在服务器上$_REQUEST["_escaped_fragment_"] 是googlebot 使用的，而不是#!。换句话说，./#!page=1 变为 ./?_escaped_fragments_=page=1。此外，对于可能使用 FF.b4 或 Chromium 的用户，history.pushState("foo":"bar", "About", "./?page=1"); 是一个很棒的命令。所以即使地址栏改变了页面也不会重新加载。这使您可以使用? 而不是#! 来保持动态内容，并在您通过电子邮件发送链接时告诉服务器我们在此页面之后，并且AJAX 不需要再次发出额外的请求。 不要使用"click here" 的链接。您正在浪费一个 SEO 机会，这让使用屏幕阅读器的人变得更加困难。 有一个XML sitemap，最好在默认位置/sitemap.xml。 当您有多个指向同一内容的 URL 时，请使用 <link rel="canonical" ... />，此问题也可以通过 Google Webmaster Tools 解决。 使用Google Webmaster Tools 和Bing Webmaster Tools。 一开始就安装Google Analytics（或者像Matomo这样的开源分析工具）。 了解robots.txt 和搜索引擎蜘蛛的工作原理。 将请求www.example.com 的请求（使用301 Moved Permanently）重定向到example.com（或相反），以防止在两个网站之间分割谷歌排名。 知道外面可能有行为不端的蜘蛛。 如果您有非文本内容，请查看 Google 的视频站点地图扩展等。Tim Farley's answer 中有一些很好的信息。

技术

了解 HTTP 以及 GET、POST、会话、cookie 以及“无状态”的含义。 根据W3C specifications写你的XHTML/HTML和CSS，并确保他们validate。此处的目标是避免浏览器怪异模式，并且作为奖励，可以更轻松地使用屏幕阅读器和移动设备等非传统浏览器。 了解 JavaScript 在浏览器中的处理方式。 了解页面使用的 JavaScript、样式表和其他资源是如何加载的，并考虑它们对感知性能的影响。它现在被广泛认为适用于您的网页的move scripts to the bottom，但通常是分析应用程序或 HTML5 垫片之类的例外。 了解 JavaScript 沙箱的工作原理，尤其是在您打算使用 iframe 时。 请注意，JavaScript 可以并且将会被禁用，因此 AJAX 是一种扩展，而不是基线。即使大多数用户现在离开它，请记住NoScript 正变得越来越流行。尽管现代爬虫程序支持索引 JavaScript 生成的内容，但请考虑为其他爬虫程序或禁用 JavaScript 的用户使用服务器端呈现。 了解difference between 301 and 302 redirects（这也是一个 SEO 问题）。 尽可能多地了解您的部署平台。 考虑使用Reset Style Sheet 或normalize.css。 考虑 JavaScript 框架（例如 jQuery、MooTools、Prototype、Dojo 或 YUI 3），它们会在使用 JavaScript 进行 DOM 操作时隐藏很多浏览器差异。 将感知性能和 JS 框架结合在一起，考虑使用诸如 Google Libraries API 之类的服务来加载框架，以便浏览器可以使用它已经缓存的框架副本，而不是从您的站点下载副本。 不要重新发明***。在做任何事情之前，先搜索一个组件或如何做的例子。有 99% 的机会有人这样做并发布了代码的 OSS 版本。 另一方面，在您确定自己的需求之前，不要从 20 个库开始。尤其是在客户端网络上，保持轻量级、快速和灵活几乎总是更重要。

错误修复

了解您将花费 20% 的时间进行编码和 80% 的维护，因此请相应地进行编码。 设置好的错误报告解决方案。 建立一个系统，供人们联系您提出建议和批评。 记录应用程序如何为未来的支持人员和维护人员工作。 经常备份！ （并确保这些备份正常运行）制定恢复策略，而不仅仅是备份策略。 使用版本控制系统来存储您的文件，例如Subversion、Mercurial 或Git。 不要忘记进行验收测试。像Selenium 这样的框架可以提供帮助。尤其是当您完全自动化测试时，可能会使用持续集成工具，例如 Jenkins。 使用log4j、log4net 或log4r 等框架确保您有足够的日志记录。如果您的实际网站出现问题，您需要找到一种方法来找出问题所在。 记录时请确保捕获已处理的异常和未处理的异常。报告/分析日志输出，因为它会向您显示您网站中的关键问题。

其他

同时实施服务器端和客户端监控和分析（应该是主动的而不是被动的）。 使用 UserVoice 和 Intercom 等服务（或任何其他类似工具）与您的用户保持联系。 关注Vincent Driessen的Git branching model

省略了很多东西，不一定是因为它们不是有用的答案，而是因为它们要么太详细，超出范围，要么对于想要了解他们应该知道的事情的概述的人来说太过分了。请随时编辑此内容，我可能遗漏了一些内容或犯了一些错误。

【讨论】：

您的一些 SEO 建议很糟糕。如果您使用表格或 div 并不重要（谷歌自己证实了这一点）。那个 SEF URL 的东西......我讨厌那些“假 URL”，其中 ID 是唯一真正确定页面的东西。 “45-blah”将是同一页。它也不是用户友好的。

然后编辑它。我并没有写大部分内容：我只是在维护它——我继承了一份工作，因为我提出了这个问题，专门征求了这个更大的答案，我真的很想看看我们能想出什么.贡献越多越好。

另一个注意事项：如果您确实回来编辑此内容，请尽量尊重所写内容。不要只是删除您不同意的部分：实际上要花时间解决缺点并提供更好的东西。

我建议您添加到安全部分的一件事是，您提供的所有文件都应与允许文件夹的白名单进行比较，或者与网络服务器“监禁”。这会阻止某人使用http://server/download.php?file=../../etc/password。永远不要向用户公开文件路径。

举个例子，你不只是跳进车里开始开车。取而代之的是，您参加有关该车正确操作的课程，并且最终必须通过测试证明您可以驾驶。对某些人来说，这需要许多、许多、许多小时的学习。是的，我会将学习如何正确构建 Web 应用程序与学习驾驶汽车等同起来，因为与简单的挡泥板弯曲相比，未能正确构建应用程序肯定会对人们的生活造成更大程度的破坏，包括更大的经济损失。死亡？好吧，这取决于开发人员搞砸了哪种类型的应用程序。