Những chi tiết kỹ thuật nào mà một lập trình viên của một ứng dụng web nên xem xét trước khi công khai trang web?

Những gì một lập trình viên nên thực hiện các chi tiết kỹ thuật của một ứng dụng web xem xét trước khi công khai trang web? Nếu Jeff Atwood có thể quên đi HttpOnly cookie , bản đồ website , và giả mạo yêu cầu cross-site tất cả trong cùng một trang web , những gì điều quan trọng tôi có thể quên không?

Tôi đang suy nghĩ về điều này từ quan điểm của một nhà phát triển web, để người khác tạo ra thiết kế và nội dung thực sự cho trang web. Vì vậy, trong khi khả năng sử dụng và nội dung có thể quan trọng hơn nền tảng, thì lập trình viên ít nói về điều đó. Điều bạn cần lo lắng là việc triển khai nền tảng của bạn ổn định, hoạt động tốt, an toàn và đáp ứng bất kỳ mục tiêu kinh doanh nào khác (như không tốn quá nhiều chi phí, mất quá nhiều thời gian để xây dựng và xếp hạng tốt với Google như hỗ trợ nội dung).

Hãy nghĩ về điều này từ góc độ của một nhà phát triển đã thực hiện một số công việc cho các ứng dụng kiểu mạng nội bộ trong một môi trường khá đáng tin cậy và sắp có cú đánh đầu tiên và đưa ra một trang web phổ biến tiềm năng cho toàn bộ web thế giới xấu lớn.

Ngoài ra, tôi đang tìm kiếm một cái gì đó cụ thể hơn là một phản ứng "tiêu chuẩn web" mơ hồ. Ý tôi là, HTML, JavaScript và CSS qua HTTP được đưa ra khá nhiều, đặc biệt là khi tôi đã xác định rằng bạn là nhà phát triển web chuyên nghiệp. Vì vậy, đi ngoài ra, Những tiêu chuẩn? Trong hoàn cảnh nào, và tại sao? Cung cấp một liên kết đến đặc điểm kỹ thuật của tiêu chuẩn.

Ý tưởng ở đây là hầu hết chúng ta nên đã biết hầu hết những gì có trong danh sách này. Nhưng có thể có một hoặc hai mục mà bạn chưa thực sự xem trước đó, không hiểu đầy đủ hoặc thậm chí có thể chưa bao giờ nghe nói đến.

Giao diện và trải nghiệm người dùng

• Xin lưu ý rằng các trình duyệt triển khai các tiêu chuẩn không nhất quán và đảm bảo trang web của bạn hoạt động hợp lý trên tất cả các trình duyệt chính. Ở thử nghiệm tối thiểu đối với công cụ Gecko gần đây ( Firefox ), công cụ WebKit ( Safari và một số trình duyệt di động), Chrome , các trình duyệt IE được hỗ trợ của bạn (tận dụng hình ảnh VPC tương thích ứng dụng ) và Opera . Cũng xem xét cách trình duyệt hiển thị trang web của bạn trong các hệ điều hành khác nhau.
• Xem xét cách mọi người có thể sử dụng trang web ngoài các trình duyệt chính: điện thoại di động, trình đọc màn hình và công cụ tìm kiếm chẳng hạn. - Một số thông tin về khả năng truy cập: WAI và Mục508 , Phát triển di động: MobiForge .
• Dàn dựng: Cách triển khai các bản cập nhật mà không ảnh hưởng đến người dùng của bạn. Có sẵn một hoặc nhiều môi trường thử nghiệm hoặc dàn dựng để thực hiện các thay đổi về kiến ​​trúc, mã hoặc quét nội dung và đảm bảo rằng chúng có thể được triển khai theo cách được kiểm soát mà không phá vỡ bất cứ điều gì. Có một cách tự động sau đó triển khai các thay đổi được phê duyệt cho trang web trực tiếp. Điều này được thực hiện hiệu quả nhất cùng với việc sử dụng hệ thống kiểm soát phiên bản (git, Subversion, v.v.) và cơ chế xây dựng tự động (Ant, NAnt, v.v.).
• Không hiển thị lỗi không thân thiện trực tiếp với người dùng.
• Đừng đặt địa chỉ email của người dùng ở dạng văn bản đơn giản vì chúng sẽ bị spam đến chết.
• Thêm thuộc tính rel="nofollow"vào các liên kết do người dùng tạo để tránh thư rác .
• Xây dựng các giới hạn được xem xét tốt vào trang web của bạn - Điều này cũng thuộc Bảo mật.
• Tìm hiểu làm thế nào để tăng cường tiến bộ .
• Chuyển hướng sau một POST nếu POST đó thành công, để ngăn làm mới gửi lại.
• Đừng quên tiếp cận tài khoản. Đó luôn là một ý tưởng tốt và trong một số trường hợp nhất định, đó là một yêu cầu pháp lý . WAI-ARIA và WCAG 2 là những tài nguyên tốt trong lĩnh vực này.
• Đọc Đừng làm tôi suy nghĩ .

Bảo vệ

• Rất nhiều thứ để tiêu hóa nhưng hướng dẫn phát triển OWASP bao gồm bảo mật trang web từ trên xuống dưới.
• Biết về Tiêm đặc biệt là SQL và cách phòng ngừa.
• Không bao giờ tin tưởng đầu vào của người dùng, cũng như bất kỳ thứ gì khác có trong yêu cầu (bao gồm cookie và các giá trị trường biểu mẫu ẩn!).
• Mật khẩu băm sử dụng muối và sử dụng các loại muối khác nhau cho các hàng của bạn để ngăn chặn các cuộc tấn công cầu vồng. Sử dụng thuật toán băm chậm, chẳng hạn như bcrypt (thời gian thử nghiệm) hoặc tiền điện tử (thậm chí mạnh hơn, nhưng mới hơn) ( 1 , 2 ), để lưu trữ mật khẩu. ( Cách lưu trữ mật khẩu an toàn ). Các NIST cũng chấp thuận PBKDF2 để băm mật khẩu ", và nó FIPS chấp thuận bằng .NET (thông tin thêm ở đây ). Tránh sử dụng MD5 hoặc SHA gia đình trực tiếp.
• Đừng cố gắng đưa ra hệ thống xác thực ưa thích của riêng bạn . Đó là một điều dễ dàng để có được sai lầm theo những cách tinh tế và không thể kiểm chứng và bạn thậm chí sẽ không biết điều đó cho đến khi bạn bị hack.
• Biết các quy tắc để xử lý thẻ tín dụng . ( Xem câu hỏi này là tốt )
• Sử dụng SSL / TLS / HTTPS cho bất kỳ trang web nào nhập dữ liệu nhạy cảm (như thông tin đăng nhập, Thông tin nhận dạng cá nhân, thông tin thẻ tín dụng). Let Encrypt là một cơ quan chứng nhận miễn phí có thể giúp đỡ.
• Ngăn chặn chiếm quyền điều khiển phiên .
• Tránh kịch bản chéo trang (XSS).
• Tránh các giả mạo yêu cầu trang web chéo (CSRF).
• Tránh Clickjacking .
• Luôn cập nhật (các) hệ thống của bạn với các bản vá mới nhất.
• Đảm bảo thông tin kết nối cơ sở dữ liệu của bạn được bảo mật.
• Giữ cho mình thông báo về các kỹ thuật tấn công mới nhất và các lỗ hổng ảnh hưởng đến nền tảng của bạn.
• Đọc Cẩm nang bảo mật trình duyệt Google .
• Đọc Cẩm nang của ứng dụng web .
• Xem xét Nguyên tắc đặc quyền tối thiểu . Cố gắng chạy máy chủ ứng dụng của bạn dưới dạng không root . ( ví dụ tomcat )
• Đặt rel="noopener noreferrer"tất cả các liên kết do người dùng cung cấp với target="_blank"để ngăn JavaScript trên trang đích chuyển hướng trang của bạn đến một nơi khác, chẳng hạn như trang đăng nhập giả mạo. Thêm thông tin
• Cân nhắc sử dụng Chính sách bảo mật nội dung nghiêm ngặt .

Hiệu suất

• Triển khai bộ đệm ẩn nếu cần thiết, hiểu và sử dụng bộ đệm HTTP đúng cách cũng như Bản kê khai HTML5 .
• Tối ưu hóa hình ảnh - không sử dụng hình ảnh 20 KB cho nền lặp lại.
• Nén nội dung cho tốc độ, xem brotli , gzip / deflate ( defatter là tốt hơn ).
• Kết hợp / ghép nhiều biểu định kiểu hoặc nhiều tệp tập lệnh để giảm số lượng kết nối trình duyệt và cải thiện khả năng gzip để nén các bản sao giữa các tệp.
• Hãy xem trang web Hiệu suất đặc biệt của Yahoo , rất nhiều hướng dẫn tuyệt vời, bao gồm cải thiện hiệu suất mặt trước và công cụ YSlow của họ (yêu cầu Firefox, Safari, Chrome hoặc Opera). Ngoài ra, tốc độ trang của Google (sử dụng với tiện ích mở rộng trình duyệt ) là một công cụ khác để định hình hiệu suất và nó cũng tối ưu hóa hình ảnh của bạn.
• Sử dụng CSS Image Sprites cho các hình ảnh nhỏ liên quan như thanh công cụ (xem điểm "thu nhỏ yêu cầu HTTP")
• Sử dụng các họa tiết hình ảnh SVG cho các hình ảnh nhỏ liên quan như thanh công cụ. Màu SVG là một chút khó khăn. Bạn có thể đọc về nó ở đây .
• Các trang web bận rộn nên xem xét phân chia các thành phần trên các tên miền . Đặc biệt...
• Nội dung tĩnh (ví dụ: hình ảnh, CSS, JavaScript và nói chung là nội dung không cần quyền truy cập vào cookie) nên đi vào một tên miền riêng không sử dụng cookie , vì tất cả cookie cho một tên miền và tên miền phụ của nó được gửi với mọi yêu cầu tới tên miền và tên miền phụ của nó. Một lựa chọn tốt ở đây là sử dụng Mạng phân phối nội dung (CDN), nhưng hãy xem xét trường hợp CDN đó có thể thất bại bằng cách bao gồm các CDN thay thế hoặc các bản sao cục bộ có thể được phục vụ thay thế.
• Tối thiểu hóa tổng số yêu cầu HTTP cần thiết cho trình duyệt để hiển thị trang.
• Chọn một công cụ mẫu và kết xuất / biên dịch trước nó bằng cách sử dụng các tác vụ chạy như gulp hoặc grunt
• Hãy chắc chắn rằng có một favicon.icotập tin trong thư mục gốc của trang web, tức là /favicon.ico. Các trình duyệt sẽ tự động yêu cầu nó , ngay cả khi biểu tượng không được đề cập trong HTML. Nếu bạn không có /favicon.ico, điều này sẽ dẫn đến rất nhiều 404, làm cạn kiệt băng thông máy chủ của bạn.

SEO (Tối ưu hóa công cụ tìm kiếm)

• Sử dụng URL "thân thiện với công cụ tìm kiếm", tức là sử dụng example.com/pages/45-article-titlethay vìexample.com/index.php?page=45
• Khi sử dụng #cho nội dung động thay đổi #thành #!và sau đó trên máy chủ $_REQUEST["_escaped_fragment_"]là những gì googlebot sử dụng thay vì #!. Nói cách khác, ./#!page=1trở thành ./?_escaped_fragments_=page=1. Ngoài ra, đối với người dùng có thể đang sử dụng FF.b4 hoặc Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");là một lệnh tuyệt vời. Vì vậy, mặc dù thanh địa chỉ đã thay đổi, trang không tải lại. Điều này cho phép bạn sử dụng ?thay vì #!giữ nội dung động và cũng cho máy chủ biết khi bạn gửi email liên kết mà chúng tôi đang ở sau trang này và AJAX không cần phải thực hiện thêm yêu cầu nào nữa.
• Đừng sử dụng các liên kết có nội dung "bấm vào đây" . Bạn đang lãng phí một cơ hội SEO và nó khiến mọi người có trình đọc màn hình khó khăn hơn.
• Có sơ đồ trang web XML , tốt nhất là ở vị trí mặc định /sitemap.xml.
• Sử dụng <link rel="canonical" ... />khi bạn có nhiều URL trỏ đến cùng một nội dung, vấn đề này cũng có thể được giải quyết từ Công cụ quản trị trang web của Google .
• Sử dụng Công cụ quản trị trang web của Google và Công cụ quản trị trang web Bing .
• Cài đặt Google Analytics ngay khi bắt đầu (hoặc một công cụ phân tích nguồn mở như Piwik ).
• Biết cách robot.txt và công cụ tìm kiếm hoạt động.
• Chuyển hướng yêu cầu (sử dụng 301 Moved Permanently) yêu cầu www.example.comđến example.com(hoặc chiều ngược lại) để ngăn chặn tách google xếp hạng giữa cả hai trang web.
• Biết rằng có thể có những con nhện cư xử tồi tệ ngoài kia.
• Nếu bạn có nội dung không phải là văn bản, hãy xem các tiện ích mở rộng sơ đồ trang web của Google cho video, v.v. Có một số thông tin tốt về câu trả lời này của Tim Farley .

Công nghệ

• Hiểu HTTP và những thứ như GET, POST, phiên, cookie và ý nghĩa của nó là "không trạng thái".
• Viết XHTML / HTML và CSS của bạn theo thông số kỹ thuật của W3C và đảm bảo chúng xác thực . Mục tiêu ở đây là để tránh các chế độ quirks của trình duyệt và như một phần thưởng giúp làm việc dễ dàng hơn nhiều với các trình duyệt phi truyền thống như trình đọc màn hình và thiết bị di động.
• Hiểu cách JavaScript được xử lý trong trình duyệt.
• Hiểu cách JavaScript, biểu định kiểu và các tài nguyên khác được sử dụng bởi trang của bạn được tải và xem xét tác động của chúng đối với hiệu suất được nhận biết . Hiện tại, nó được coi là phù hợp để di chuyển các tập lệnh xuống cuối trang của bạn với các ngoại lệ thường là những thứ như ứng dụng phân tích hoặc miếng chêm HTML5.
• Hiểu cách hoạt động của hộp cát JavaScript, đặc biệt nếu bạn có ý định sử dụng iframe.
• Xin lưu ý rằng JavaScript có thể và sẽ bị vô hiệu hóa và do đó AJAX là phần mở rộng, không phải là đường cơ sở. Ngay cả khi hầu hết người dùng bình thường rời khỏi nó bây giờ, hãy nhớ rằng NoScript đang trở nên phổ biến hơn, các thiết bị di động có thể không hoạt động như mong đợi và Google sẽ không chạy hầu hết JavaScript của bạn khi lập chỉ mục trang web.
• Tìm hiểu sự khác biệt giữa chuyển hướng 301 và 302 (đây cũng là một vấn đề SEO).
• Tìm hiểu càng nhiều càng tốt về nền tảng triển khai của bạn.
• Xem xét sử dụng Đặt lại Bảng định kiểu hoặc normalize.css .
• Xem xét các khung JavaScript (như jQuery , MooTools , Prototype , Dojo hoặc YUI 3 ), sẽ ẩn rất nhiều sự khác biệt của trình duyệt khi sử dụng JavaScript để thao tác DOM.
• Kết hợp các khung công tác và hiệu suất nhận thức cùng nhau, hãy xem xét sử dụng một dịch vụ như API thư viện của Google để tải các khung để trình duyệt có thể sử dụng một bản sao của khung mà nó đã lưu trong bộ nhớ cache thay vì tải xuống một bản sao từ trang web của bạn.
• Đừng phát minh lại bánh xe. Trước khi thực hiện tìm kiếm BẤT CỨ tìm kiếm một thành phần hoặc ví dụ về cách thực hiện. Có 99% khả năng ai đó đã thực hiện và phát hành phiên bản OSS của mã.
• Bên cạnh đó, đừng bắt đầu với 20 thư viện trước khi bạn quyết định nhu cầu của mình là gì. Đặc biệt trên trang web phía khách hàng, nơi hầu như luôn luôn quan trọng hơn để giữ mọi thứ nhẹ, nhanh và linh hoạt.

Sửa lỗi

• Hiểu được bạn sẽ dành 20% thời gian để mã hóa và 80% cho việc duy trì, do đó, mã hóa phù hợp.
• Thiết lập một giải pháp báo cáo lỗi tốt.
• Có một hệ thống để mọi người liên hệ với bạn với những gợi ý và phê bình.
• Tài liệu về cách ứng dụng hoạt động cho nhân viên hỗ trợ trong tương lai và những người thực hiện bảo trì.
• Hãy sao lưu thường xuyên! (Và đảm bảo rằng các bản sao lưu đó là chức năng) Có chiến lược khôi phục, không chỉ là chiến lược sao lưu.
• Sử dụng hệ thống kiểm soát phiên bản để lưu trữ các tệp của bạn, chẳng hạn như Subversion , Mercurial hoặc Git .
• Đừng quên làm bài kiểm tra chấp nhận của bạn. Các khung như Selenium có thể giúp đỡ. Đặc biệt là nếu bạn tự động hóa hoàn toàn thử nghiệm của mình, có lẽ bằng cách sử dụng công cụ Tích hợp liên tục, chẳng hạn như Jenkins .
• Hãy chắc chắn rằng bạn có đủ đăng nhập tại chỗ bằng cách sử dụng các khung như log4j , log4net hoặc log4r . Nếu có sự cố xảy ra trên trang web trực tiếp của bạn, bạn sẽ cần một cách để tìm hiểu những gì.
• Khi đăng nhập, đảm bảo bạn nắm bắt được cả các ngoại lệ được xử lý và các ngoại lệ chưa được xử lý. Báo cáo / phân tích đầu ra nhật ký, vì nó sẽ cho bạn biết các vấn đề chính trong trang web của bạn.

Khác

• Thực hiện cả phân tích và giám sát phía máy chủ và phía máy khách (người ta nên chủ động hơn là phản ứng).
• Sử dụng các dịch vụ như UserVoice và Liên lạc (hoặc bất kỳ công cụ tương tự nào khác) để liên tục giữ liên lạc với người dùng của bạn.
• Theo mô hình phân nhánh Git của Vincent Driessen

Rất nhiều thứ bị bỏ qua không nhất thiết vì chúng không phải là câu trả lời hữu ích, mà vì chúng quá chi tiết, nằm ngoài phạm vi hoặc đi quá xa để ai đó muốn tìm hiểu tổng quan về những điều họ nên biết. Xin vui lòng chỉnh sửa điều này là tốt, tôi có thể đã bỏ lỡ một số thứ hoặc mắc một số sai lầm.