techover.io

Tag: web

  • HTTP vs HTTPS: Làm thế nào để website bảo mật hơn với SSL

    HTTP vs HTTPS: Làm thế nào để website bảo mật hơn với SSL

    Vào tháng 8 năm 2014, Google công bố sử dụng HTTPS để khắc phục những vẫn đề bảo mật mà phương thức HTTP đang gặp phải.

    Đối với hầu hết các công ty, việc Google khuyến cáo sử dụng HTTPS là lý do để thực hiện chuyển đổi sang giao thức đó, nhưng bản thân mỗi chúng ta cũng cần hiểu sự khác biệt giữa chúng – ưu và nhược điểm của HTTP và HTTPS. Tôi sẽ bắt đầu bằng việc giới thiệu tổng quan về giao thức HTTP và sau đó xem xét lý do tại sao Google muốn các trang web chuyển đổi sang sử dụng HTTPS.

    HTTP là gì, hoạt động như thế nào, và tại sao nó không được bảo mật?

    HTTP – HyperText Transfer Protocol, là một giao thức đã tồn tại hơn 15 năm, dùng để truyền tải thông tin qua Internet.

    Cũng như nhiều giao thức khác, HTTP hoạt động theo mô hình Client – Server. Trình duyệt web tạo request được gọi là Client, nơi nhận và phản hồi request đó là Server.

    Giả sử, bạn đang ngồi trong quán cafe và thử đăng nhập Facebook thông qua wifi của quán (giả định là Facebook đang dùng HTTP). Mạng wifi của quán là public, bất cứ ai kết nối với nó đều có thể truy cập dữ liệu đang được chuyển giao.

    Bây giờ chúng ta hãy xem những gì đang xảy ra với dữ liệu của bạn nếu như website sử dụng HTTP.

    Dữ liệu ở đây là bao gồm tất cả thông tin đăng nhập, mật khẩu, … cho tài khoản Facebook của bạn.

    Để đăng nhập vào Facebook, bạn cần nhập các thông tin như email, số điện thoại và mật khẩu. Ngay khi bạn nhấp vào nút đăng nhập, dữ liệu của bạn sẽ được gửi đến Server của Facebook. Server nhận dữ liệu, và xác thực nó. Nếu thông tin nhập là chính xác, Server sẽ gửi về HTTP status là “OK”, và bạn được đăng nhập vào tài khoản của mình. Mọi thứ có vẻ ez.

    Nhưng vấn để xảy ra ở đây là, nếu dữ liệu của bạn gửi lên server thông qua HTTP, thì nó sẽ không được mã hóa (HTTP không mã hóa dữ liệu) và vì vậy, bất kỳ dữ liệu nào được truyền thông qua giao thức HTTP đều có thể bị đánh cắp hoặc thay đổi từ bên thứ ba.

    Có thể bạn chưa bao giờ nghe tới Network sniffing attack, nhưng loại tấn công đó khá phổ biến.

    Sniffing attacks là một loại tấn công mà các Hacker sử dụng để lấy cắp thông tin “nhạy cảm” của bạn (vd: password, creadit card, users id, …).

    Để thực hiện việc này, các hacker thường sử dụng Sniffer – một chương trình có thể bắt được các gói tin truyền qua mạng.

    Sniffer là công cụ để phân tích và khắc phục các sự cố mạng thông qua việc bắt các gói tin, nhưng Hacker có thể lợi dụng điều đó để sử dụng chúng vào mục đích bất chính.

    Nếu các gói tin không được mã hóa, dữ liệu trong các gói tin này nó thể được lấy bởi một Sniffer. Sniffer sẽ phân tích và đọc nội dung gói tin, từ đó, các hacker đã có thể lấy được các thông tin private của bạn một cách dễ dàng.

    Như chúng ta đã thấy, HTTP có một điểm yếu chí cmn mạng – thông tin chuyển tới Server thông qua HTTP không được mã hóa. Điều đó, về mặt lý thuyết, có thể bị chặn bởi Hacker bất cứ lúc nào.

    Đối với những trang web thuần túy để đọc báo hay xem thông tin thì không có vấn đề gì lớn. Nhưng nó rất nguy hiểm khi bạn thực hiện các giao dịch trực tuyến, mà trong đó phải cung cấp các thông tin cá nhân quan trọng như giao dịch ngân hàng, mua sắm, …

    Tuy nhiên, điểm yếu đó của HTTP có thể được giải quyết dễ dàng bằng cách sử dụng 1 protocol khác – HTTPS.

    HTTPS ngoài Sniffing attacks ra cũng có thể bảo vệ bạn khỏi những kiểu tấn công khác như man-in-the-middle attacks, DNS rebinding, replay attacks. Nhưng trong bài viết này, tôi chỉ để cập tới cách để HTTPS bảo vệ bạn khỏi Sniffing attacks đã nói ở trên thôi.

    HTTPS là gì và làm thế nào nó có thể bảo vệ website của bạn

    Giống như HTTP, HTTPS cũng là một giao thức giúp truyền thông tin giữa Client và Server. (Nó là một phiên bản của HTTP với thêm chứ “S” ở cuối – viết tắt của “Secure”). HTTPS bảo mật dữ liệu của bạn bằng cách sử dụng giao thức TSL (Transport Layer Security) hay còn gọi là SSL. Nhưng SSL là gì?

    SSL là tiêu chuẩn bảo mật cung cấp 3 lớp bảo vệ:

    • Mã hóa (Encryption): tất cả dữ liệu được gửi giữa browsers (Client) và Server đều được mã hóa. Nếu Hacker lấy được gói tin đó, cũng không thể giải mã được.
    • Toàn vẹn dữ liệu (Data integrity): Đảm bảo dữ liệu truyền đi không thể sửa đổi hoặc bị hỏng mà không bị phát hiện.
    • Xác thực (Authentication): Xác minh xem bạn thực sự đang giao tiếp với Server đã định hay không.

    Để ý một chút, khi truy cập website sử dụng HTTPS, trên url của bạn sẽ hiển thị ra chữ màu xanh như sau:

    Hoạt động của SSL

    SL sử dụng cái gọi là Public Key Cryptography hoặc hệ thống Public Key Infrastructure (PKI). Hệ thống PKI (key không đối xứng) sử dụng 2 key khác nhau để mã hóa thông tin: public key và private key. Bất cứ thứ gì được mã hóa bằng public key đều chỉ có thể giải mã bằng private key tương ứng và ngược lại.

    Lưu ý rằng, private key – giống như cái tên của nó, nên được bảo vệ kỹ và chỉ được truy cập bởi chính owner mà thôi. Với một trang web, private key phải được giữ an toàn trên Server. Nhưng ngược lại, public key lại được cấp phát công khai cho bất kỳ ai, và tất cả mọi người đều cần nó để giải mã thông tin đã được mã hóa trước đấy bằng private key. Bây giờ, chúng ta đã hiểu cách làm việc của cặp public key và private key, ta sẽ tiếp tục mô tả quá trình hoạt động SSL thông qua từng bước như sau.

    Giả sử bạn truy cập 1 website có sử dụng HTTPS:

    • Bước 1: Thiết lập một “giao tiếp” an toàn giữa Server và Client – còn được gọi là Handshake (bắt tay). Quá trình Handshake được bắt đầu khi browsers truy cập trang web thông qua url. Bằng cách request trên, Client sẽ khởi tạo kết nối SSL với Server cùng với thông tin về phiên bản và kiểu mã hóa. Việc Client gửi request và khởi tạo kết nối SSL được gọi là client hello.
    • Bước 2: Bước tiếp theo được gọi là server hello. Sau khi nhận được yêu cầu từ Client, Server trả về cho Client SSL certificate cùng với public key của nó. Hoàn tất quá trình chào hỏi xã giao.
    • Bước 3: Client nhận được dữ liệu từ Server, browser sẽ xác minh SSL certificate đó. Những certificate này được kiểm soát bởi các tổ chức bảo mật (Certificate Authority) như Symantec, Comodo, GoDaddy. SSL Certificate là một khối dữ liệu bao gồm nhiều thông tin về server như:
      • Tên domain.
      • Tên công ty sở hữu.
      • Thời gian certificate được cấp.
      • Thời hạn certificate.
      • Public key.
    • Bước 4: Sau khi xác minh xong, Browser sẽ sinh ra 1 Key - K và được mã hóa bởi public key nhận được từ bước 2. K sẽ được sử dụng để mã hóa tất cả dữ liệu truyền tải giữa Client và Server.
    • Bước 5: Do quá trình mã hóa dữ liệu sử dụng PKI (key đối xứng), nên Client cần gửi cho Server cái khóa K này để giải mã gói tin. Server sẽ dùng private key để giải mã gói tin này và lấy được thông tin về khóa K.
    • Bước 6: Từ đây, các thông tin truyền tải giữa Client và Server đều được mã hóa bằng khóa K. Khóa K này là unique và chỉ có hiệu lực trong thời gian Session đó tồn tại.

    Việc sử dụng HTTPS sẽ bảo vệ trang web của bạn tới những kiểu tấn công mà tôi đã đề cập trước đó. Bạn có authentication, bạn có thể biết rằng mình đang giao tiếp một cách an toàn với Server dự định. Dữ liệu của bạn được mã hóa encryption – ngay cả khi sniffer lấy được gói tin, cũng không thể giải mã được nội dung bên trong. Và tất nhiên bạn có được toàn vẹn dữ liệu data integrity, vì vậy bạn có thể truyền những dữ liệu nhạy cảm mà không cần lo lắng về việc nó bị hỏng hoặc sửa đổi mà không phát hiện ra.

    Bạn có nên sử dụng HTTPS

    Trước khi đưa ra quyết định sử dụng HTTPS thay cho HTTP, tôi sẽ tổng hợp những lợi ích chính nếu website của bạn sử dụng HTTPS:

    • Security: Tất cả thông tin truyền tải giữa Client và Server đều được mã hóa và xác minh. Điều này giúp bạn chống được một số kiểu tấn công của hacker như man-in-the-middle attacks, DNS rebinding, replay attacks.
    • Trust: Người dùng sẽ cảm thấy an tâm với trang web của bạn hơn. HTTPS giúp xây dựng lòng tin với họ, nhất là khi web của bạn cung cấp các dịch vụ dính đến tiền (yaoming).
    • SEO: Việc sử dụng HTTPS sẽ tăng thứ hạng tìm kiếm trang web của bạn trên các search engine.

    Nguồn:

  • Sự khác nhau giữa Authentication và Authorization

    Sự khác nhau giữa Authentication và Authorization

    1. Authentication

    Authentication là xác thực, chỉ quá trình định danh một tài khoản đang vào hệ thống chính là người đó chứ không phải ai khác. Đây là bước ban đầu của mọi hệ thống có yếu tố người dùng. Nếu không có bước xác thực này, hệ thống của bạn sẽ không biết được người đang truy cập vào hệ thống là ai để có các phản hồi phù hợp, thường biểu hiện ở hình thức đơn giản nhất chính là form đăng nhập vào hệ thống. Đây là mô hình xác thực dựa trên yếu tố “mật khẩu”. Mật khẩu là một trong những phương pháp được triển khai cho hệ thống xác thực (authentication). Một số phương thức xác thực thông dụng khác là khóa (public & private), sinh học (vân tay, tròng mắt, khuôn mặt)…

    2. Authorization

    Sau khi xác định được “danh tính” của tài khoản thì hệ thống mới chỉ trả lời được câu hỏi “Đó là ai?”, chúng ta sẽ tiến hành một bước quan trọng không kém đó là trả lời câu hỏi “Người đó có thể làm được gì?”, hay xác định quyền (phân quyền) của tài khoản hiện tại vừa mới được xác thực.
    Hệ thống của bạn có thể sẽ rất phức tạp bởi nhiều tính năng quan trọng và mạng lưới phòng ban dày đặc và cần phân chia quyền sử dụng rõ ràng nên việc thiết kế một hệ thống phân quyền cho từng thành viên là một việc làm cực kỳ quan trọng và cần thiết.

    Các hình thức phân quyền thường gặp là:

    + Role-based authorization: Phân quyền dựa trên vai trò của người dùng. Ví dụ trong WordPress có các role như là  Subscriber, Contributor, Author, Editor, Administrator và mỗi một role sẽ có những quyền khác nhau và mỗi người dùng sẽ được phân role có quyền tương ứng. Đối với những hệ thống có nhiều người dùng thì role-based là cách tiếp cận tốt nhất để tiết kiệm thời gian trong việc phân quyền.

    + Object-based authorization: Phân quyền theo đối tượng. Cách này sẽ phân quyền cho từng đối tượng cụ thể. Ví dụ những đối tượng trong nhóm A, B được phân quyền chỉnh sửa các bài viết trong danh mục. Nhưng đối tượng trong nhóm A chỉ chỉnh sửa được bài viết trong danh mục C, đối trượng trong nhóm B chỉ chỉnh sửa bài viết trong danh mục D.

    Nguồn tham khảo thêm:

    http://searchsecurity.techtarget.com/definition/authentication


  • Web Architecture?

    Web Architecture?

    Bài này thực ra là đi copy từ đây, nhưng dịch lại theo ngôn ngữ dễ hiểu thôi : ).

    Web hiện tại thì nó như thế này : )

    Trông có vẻ phức tạp nhưng gần như mình sử dụng hết các phần trong này đó. Thông thường thì mình không để ý đến 9a và 9c, 10 cũng khá optional nhưng thôi cứ đề cập cả.

    Câu chuyện ở trong bài viết hơi khác nhưng mình sẽ diễn giải lại thế này.

    Khi bạn tìm kiếm techover trên Google, kết quả đầu tiên tìm được sẽ là: https://magz.techover.io/. Khi ấn vào link đó, trình duyệt sẽ truy cập đến DNS server tìm kiếm cách truy cập đến magz.techover.io, sau đó trình duyệt sẽ gửi request. Request đầu tiên sẽ truy cập đến CDN Cloudfront của magz.techover.io, các request đã cache sẽ đựoc response luôn từ Edge Location của Cloudfront. Các request khác sẽ đến Load Balancer, và chọn ngẫu nhiên 1 trong 5 Server LightSail của techover. Webserver sẽ truy vấn vào database, tra cứu một số thông tin về các hình ảnh có trong bài viết từ S3 và thực hiện thay đổi database. Và tất nhiên giờ đây, Server sẽ luôn response cho người đọc chế độ xem dưới dạng HTML và gửi lại cho trình duyệt của người dùng, trước tiên chuyển qua bộ cân bằng tải. Trang này chứa các tài sản Javascript và CSS mà mấy cái này thì lại được cache ở CDN ở ban đầu ấy, vì vậy trình duyệt của người dùng liên hệ với CDN để lấy nội dung. Cuối cùng, trình duyệt hiển thị rõ ràng trang cho người dùng xem. Tiếp theo, khi người đọc tìm kiếm bài viết tương tự Server sẽ gửi yêu cầu đến Fulltext Search Service bằng cách sử dụng tiêu đề bài viết và các từ khóa có trong nội dung. Tương lai gần, dịch vụ này cũng phục vụ cho custom feed cho từng user một dựa trên các sở thích hay xu hướng tìm kiếm các từ khóa ở techover. Nhưng bây giờ mỗi khi người dùng đăng bài, chúng tôi sẽ lưu trữ tạm kết quả của trang home ở một Server cache Redis để phục vụ người dùng tốt hơn. Sau đó người dùng viết bài, các tác vụ upload ảnh, resize khá nặng vì vậy sẽ đẩy các công việc này vào queue SQS và được thực hiện bởi các worker, mà các worker này sẽ xử lý không đồng bộ, cập nhật database phù hợp với kết quả, các hình ảnh này sau khi được xử lý xong sẽ được lưu trữ trên S3 và có một CDN Cloudfront khác phục vụ request. Đấy là toàn bộ bức tranh của trang techover hiện tại, cũng khá đủ component.

    Tiếp theo thì mình sẽ đi qua từng cái ở trên kia, mấy cái khóa ở trường đại học thường sẽ dùng số 101 để cho các khóa introduction nên ông tác giả để như thế. Chắc sẽ có một vài series 102, 103 để nói rõ hơn.

    DNS

    Domain Name System, tên nó là thế. Gần như đây là một thứ cốt lõi trong thế giới Web hiện nay. Ở mức cơ bản nhất, DNS cung cấp tra cứu key-value từ một tên miền – domain (ví dụ: google.com) đến địa chỉ IP (ví dụ: 85.129.83.120), được yêu cầu để máy tính của bạn định tuyến(route) yêu cầu đến server phù hợp. Tương tự với số điện thoại, sự khác biệt giữa tên miền và địa chỉ IP là sự khác biệt giữa cuộc gọi của Nguyen Van A, và cuộc gọi 0945123456. Giống như bạn cần một cuốn sách điện thoại để tra cứu số của A trong những ngày xưa, bạn cần DNS để tra cứu địa chỉ IP cho một tên miền. Vì vậy, bạn có thể nghĩ DNS là danh bạ điện thoại cho internet. Có nhiều chi tiết khác chúng tôi có thể đi vào đây nhưng mình sẽ bỏ qua vì nó không quan trọng cho bài 101 này.

    Thực ra có một series khác nói về cái này rõ hơn, có thể tìm thấy ở đây này.

    Load Balancer

    Cân bằng tải, thực ra trong ví dụ của techover thì Load Balancer (LB) còn sau cả CDN nhưng nó không tiêu chuẩn và không hay dùng như thế lắm nên mình để ở đây.

    Hồi ở đại học thì mọi người sẽ biết đến khái niệm mở rộng theo chiều ngang (Horizontal scaling) và mở rộng theo chiều dọc (Vertical scaling). Thì mở rộng theo chiều dọc là nâng cấp phần cứng: Ram, CPU, Bandwidth, … cho Server làm cho Server mạnh hơn đúng nghĩa theo chiều dọc, còn mở rộng theo chiều ngang là thay vì bạn nâng cấp, bạn sẽ mua thêm Server mới, đặt ngang hàng với Server cũ, không tin thì xem ở Stackoverflow này.

    Lúc phát triển một ứng dụng web, thường thì mọi người sẽ thích mở rộng theo chiều ngang hơn vì nó đơn giản, chỉ cần cài thêm server là được. Các vấn đề bất ngờ như: Server sự cố, crash, mất điện datacenter bất ngờ, sự cố thiên tai, … có thể dễ dàng được phòng chống bằng cách đưa thêm Server, ngoài ra khi có nhiều Server chúng ta sẽ có thể bảo trì một trong các Server một cách dễ dàng mà không làm ảnh hưởng đến người dùng vì vẫn còn những Server khác hoạt động. Thuật ngữ thường dùng ở đây là fault tolerant. Thứ hai, việc mở rộng theo chiều ngang cho phép các component của ứng dụng không liên kết quá chặt chẽ với nhau (low coupling) (như Web Server, Database, Service, v.v.), bằng cách cho mỗi component chạy trên một cum Server khác nhau. Cuối cùng, lý do cốt lõi nhất, đồng ý bạn có thể mở rộng theo chiều dọc tuy nhiên đến một lúc nào đó bạn không để mở rộng được nữa,ví dụ như giới hạn của rack server, của datacenter, không có máy tính nào trên thế giới đủ lớn để thực hiện tất cả các tính toán ứng dụng của bạn, trong khi đó việc mở rộng theo chiều ngang gần như không hạn chế. Ví dụ thực tế như này, Netflix một lúc có thể chạy vài chục đến vài nghìn EC2 instance mỗi loại, thậm chí có dùng cả GCP và Azure, không có Server nào đủ lớn để chạy toàn bộ ứng dụng của Netflix trên một Server duy nhất cả.

    Lan man hơi nhiều, nhưng trở lại với Load Balancer, có thể nhận ra rằng Load Balancer lại là cái không thể thiếu để thực hiện mở rộng theo chiều ngang. LB định tuyến các request từ user/client đến các Server khác nhau và đưa kết quả về lại cho user/client, mấy cái Server này thường là các bản sao của một server gốc, hay đơn thuần chỉ là bạn cài đặt lại toàn bộ Server đó. Bất kỳ Server nào trong số đó cũng nên xử lý request theo cùng một cách để nó chỉ là vấn đề phân phối các request trên toàn bộ các Server để không Server nào bị quá tải.

    Đó, Load Balancer về mặt khái niệm là đúng theo nghĩa đen, tất nhiên đằng sau đó là một loạt các công nghệ khác nhau, nhưng cuối cùng vẫn phải đề cập ở một bài viết cụ thể hơn.

    Web Application Servers

    Ở high level, các Web Application Server tương đối đơn giản để mô tả. Những server này thực thi logic nghiệp vụ cốt lõi xử lý request của người dùng và gửi lại HTML cho trình duyệt của người dùng. Để thực hiện công việc của mình, các server này có kết nối với nhiều cơ sở hạ tầng phụ trợ như database, caching, queue job, searching service, các micro-service khác, logging, v.v. Như đã đề cập ở trên, mọi người thường có sử dụng 1 hoặc nhiều load balancer trong cùng một ứng dụng. Web App thì có thể sử dụng nhiều ngôn ngữ khác nhau (Node.js, Ruby, PHP, Scala, Java, C # .NET, v.v.) và một framework MVC cho ngôn ngữ đó (Express cho Node.js, Ruby on Rails , Play Framework cho Scala, Laravel cho PHP, v.v.). Tuy nhiên, đi sâu vào chi tiết của các ngôn ngữ và khung này nằm ngoài phạm vi của bài viết này.

    Database

    Hiện nay, mỗi Web Application thường sử dụng một hoặc nhiều database để lưu trữ thông tin. Database cung cấp các cách xác định cấu trúc dữ liệu của bạn, insert dữ liệu mới, search/select dữ liệu hiện có, update hoặc xóa dữ liệu hiện có, thực hiện tính toán trên dữ liệu và hơn thế nữa. Trong hầu hết các trường hợp, các Web Application Server, cũng như các Worker Server làm việc trực tiếp một Database. Ngoài ra, mỗi Backend có thể có cơ sở dữ liệu riêng của mình và riêng biệt với với phần còn lại.

    Trong bài viết nay, thường sẽ tránh nói sâu về một loại công nghệ cụ thể, thế nên chỉ đề cập đến 2 loại database: SQL và NoQuery.

    SQL là viết tắt của Structured Query Language, ngôn ngữ này cung cấp một cách truy vấn tiêu chuẩn cho các bộ dữ liệu quan hệ có thể truy cập được đối tượng. Cơ sở dữ liệu SQL lưu trữ dữ liệu trong các bảng được liên kết với nhau thông qua các quan kệ: Id, Foreign Id . Hãy xem qua một ví dụ đơn giản về lưu trữ thông tin địa chỉ lịch sử cho người dùng. Bạn có thể có hai bảng, user và user_addresses, được liên kết với nhau bởi id người dùng. Xem hình ảnh dưới đây cho một phiên bản đơn giản. Các bảng được liên kết bằng cột user_id trong user_addresses là một Foreign key, với cột id trong bảng user.

    Nếu bạn không biết nhiều về SQL, tôi khuyên bạn nên tìm hiểu hướng dẫn như bạn có thể tìm thấy ở W3School tại đây. SQL gần như xuất hiện ở mọi Web Application Server, nhìn chung gần như bạn không thể làm Web mà không biết gì về SQL cả. NoQuery, viết tắt của từ Non-SQL, là một công nghệ cơ sở dữ liệu mới hơn đã xuất hiện để xử lý lượng dữ liệu khổng lồ có thể tạo ra Web Application với quy mô lớn (hầu hết các biến thể của SQL không thể mở rộng theo chiều ngang quá tốt và chỉ có thể mở rộng theo chiều dọc đến một điểm nhất định). Nếu bạn không biết gì về NoQuery, mình khuyên nên bắt đầu với một số link dưới đây:

    I would also keep in mind that, by and large, the industry is aligning on SQL as an interface even for NoSQL databases so you really should learn SQL if you don’t know it. There’s almost no way to avoid it these days.

    Về cơ bản cũng sẽ ghi nhớ rằng, gần như tất cả phần mềm đang liên kết với SQL như một giao diện thường thấy ngay cả đối với NoSQL, họ cũng tạo ra các framework cũng như library để hỗ trợ truy vấn NoSQL như một database SQL thông thường, thế nên thực sự cần biết về SQL, kiểu gì bạn cũng gặp những thứ này thôi.

    Caching Service

    Caching Service cung cấp một một nơi lưu trữ theo kiểu key-value đơn giản, cho phép tra cứu các thông tin với độ phức tạp O(1). Các ứng dụng thường tận dụng các Caching Service để lưu kết quả của các tính toán nặng và khó để có thể lấy lại kết quả từ cache thay vì tính toán lại chúng vào lần tiếp theo khi chúng ta cần. Một ứng dụng có thể lưu trữ kết quả từ truy vấn database, kết quả gọi đến một API ở bên ngoài, HTML cho một URL nhất định và nhiều hơn nữa. Dưới đây là một số ví dụ từ các ứng dụng trong thế giới thực:

    • Google lưu trữ kết quả tìm kiếm cho các truy vấn tìm kiếm phổ biến như Taylor Swift hay World Cup, thay vì tính lại chúng mỗi lần
    • Facebook lưu trữ nhiều dữ liệu có thể hiển thị lúc bạn đăng nhập, chẳng hạn như dữ liệu bài đăng, bạn bè, v.v. À có một bài chi tiết về vụ Facebook ở đây

    Job Queue & Servers

    Hầu hết Web Appliaction cần thực hiện một số async job ở background mà không liên quan trực tiếp đến việc tiếp nhận và đáp ứng request của người dùng. Chẳng hạn, Google cần thu thập dữ liệu và lập chỉ mục toàn bộ internet để trả về kết quả tìm kiếm. Google không làm điều này mỗi khi bạn tìm kiếm. Thay vào đó, Google thu thập dữ liệu web không đồng bộ, cập nhật các chỉ mục tìm kiếm khi duyệt các trang web. Mặc dù có các kiến ​​trúc khác nhau cho phép thực hiện async job, nhưng phổ biến nhất là kiểu Queue hay Queue Job. Cài này bao gồm hai thành phần:

    • Một là queue, tất nhiên rồi, thường thì có thể dùng database queue, Redis queue, xịn xò hơn thì dùng dịch vụ cloud như SQS của AWS hay Task Queue ở GCP, Queue này lưu trữ một danh sách các async job. Đơn giản nhất là queue FIFO
    • Hai là cái thực hiện công việc trong queue, thường được gọi là Worker hay Job Server. Bất cứ khi nào Application cần chạy một job, theo một thứ tự thông thường hoặc được xác định bởi hành động của người dùng, thì Application sẽ thêm một job vào queue. Ví dụ, Techover sử dụng queue job làm nhiều background job cần thiết cho công việc. Techover dùng các job để resize ảnh, xử lý CSV để gắn tag, cập nhật Elastic Search index, gửi email đặt lại mật khẩu và nhiều cái nữa. Đầu tiên chúng tôi sử dụng một queue FIFO đơn giản sau đó nâng cấp lên hàng đợi ưu tiên để đảm bảo rằng các hoạt động cần kíp như gửi email đặt lại mật khẩu đã được hoàn thành càng sớm càng tốt. Worker Server, thông thường được cài đặt riêng hoặc có thể chạy cùng với Application Server cho tiết kiệm tài nguyên, các Server này kiểm tra queue job để xác định xem có job nào để làm hay không và nếu có, họ sẽ lấy job (pop) ra khỏi queue và thực hiện(execute). Chi tiết về vụ ngôn ngữ và framework thì lại không đề cập ở bài viết này nhé.

    Full-text Search Service

    Nhiều Web Application, nếu không phải hầu hết đều hỗ trợ một số tính năng tìm kiếm trong đó người dùng nhập vào một đoạn keyword(query) và Web Application trả về kết quả có liên quan nhất về keyword đó. Công nghệ dùng cho chức năng này thường được gọi là Full-text Search, trong đó sử dụng một inverted index để nhanh chóng tra cứu các tài liệu có chứa các từ khóa truy vấn.

    Ví dụ cho thấy cách ba title của document được chuyển đổi thành một inverted index để tạo điều kiện tra cứu nhanh từ một từ khóa cụ thể đến các document có từ khóa đó trong title. Lưu ý, các từ phổ biến như trên mạng, trong đó có các từ phổ biến, như “in”, “the”, “with” (Stop word), thường không được đặt trong một inverted index.

    Mặc dù nó có thể thực hiện Full-text Search trực tiếp từ một số cơ sở dữ liệu (ví dụ: MySQL hỗ trợ Full-text Search), nhưng chúng ta có thể sử dụng một Search Service riêng biệt, tính toán và lưu trữ inverted index và cung cấp query interface. Full-text Search Platform nổi tiếng và phổ biến nhất hiện tại là Elaticsearch mặc dù có các tùy chọn khác như Sphinx hoặc Apache Solr.

    Services

    Khi một Application đạt đến một quy mô nhất định, có khả năng sẽ có một số Service nhất định được refactor để chạy như các Application riêng biệt. Những service này không tiếp xúc với thế giới bên ngoài nhưng sẽ tương tác cùng Application và các service khác. Ví dụ như Techover, có một số service hoạt động và theo schedule:

    • Service gửi mail
    • Service chạy hằng đêm để đồng bộ tài khoản
    • Service export file thành PDF

    Data

    Ngày nay, các công ty sống dựa vào người dùng và dữ liệu. Hầu như mọi ứng dụng ngày nay, một khi nó đạt đến một quy mô nhất định, tận dụng một data pipeline để đảm bảo rằng data có thể được thu thập, lưu trữ và phân tích. Một data pipeline điển hình có ba giai đoạn chính:

    1. Ứng dụng sẽ gửi data, điển hình là các sự kiện về tương tác của người dùng, đến data Firehose, nơi cung cấp các interface dùng để nhập và xử lý data. Thông thường, data thô được chuyển đổi hoặc xử lý thêm data và chuyển sang một Firehose khác. AWS Kinesis (bao gồm cả Kinesis Data Firehose)và Kafka là hai công nghệ phổ biến nhất cho mục đích này.
    2. Data thô cũng như data được chuyển đổi cuối cùng được lưu vào Cloud Storage. AWS Kinesis cung cấp một cài đặt Firehose, giúp lưu trữ data thô vào Cloud Storage S3.
    3. Data được chuyển đổi cũng thường được lưu vào một loại database để phân tích – Data Warehouse, cũng không phải là loại database dùng cho Application thường thấy. Ở AWS thường chúng ta sẽ dùng AWS Redshift, đây là một sản phẩm ưa chuộng của giới ít tiền nhất là các startup, bên cạnh đó các công ty lớn hơn sẽ thường sử dụng Oracle hoặc các Data Warehouse. Nếu các bộ dữ liệu đủ lớn, các Hadoop-like NoSQL như MapReduce có thể dùng để phân tích dữ liệu. Một bước cuối cùng mà thường không được hình dung trong sơ đồ kiến ​​trúc: Load data từ Application vào dịch vụ Data Warehouse. Ví dụ: tại một số trang web sẽ chuyển data từ một OLTP Database vào Redshift mỗi đêm. Việc này giúp cho các data scientist có toàn bộ dữ liệu đầy đủ nhất để phân tích và đưa ra các quyết định.

    Cloud storage

    Theo AWS: "Cloud storage là một phương thức đơn giản và có thể mở rộng để lưu trữ, truy cập và chia sẻ dữ liệu qua Internet". Bạn có thể sử dụng nó để lưu trữ và truy cập bất cứ thứ gì như khi bạn lưu trữ trên hệ thông localfile với thêm lợi ích là có thể tương tác với nó thông qua API RESTful qua HTTP. Amazon S3 cho đến nay vẫn là bộ lưu trữ đám mây tuyệt vời nhất hiện nay và là nơi Techover dùng để lưu trữ video, ảnh và âm thanh, CSS và Javascript, dữ liệu người dùng(tất nhiên là private bucket) và nhiều cái khác nữa.

    CDN – Content Delivery Network

    CDN cung cấp cách transfer các file như HTML tĩnh, CSS, Javascript và hình ảnh trên web nhanh hơn nhiều so với lấy chúng từ một Server nào đó. Nó hoạt động bằng cách distribute các content trên nhiều máy chủ (Edge Location) trên toàn thế giới, để enduser có thể tải xuống các file này từ đó thay vì máy chủ gốc. Ví dụ trong hình ảnh bên dưới, một người dùng ở Tây Ban Nha yêu cầu một trang web từ một trang web có Origin Server ở New York, nhưng các file tĩnh cho trang được tải từ Server Edge CDN, ở Anh, ở Pháp, điều này giúp người dùng tải trang nhanh hơn trải nghiệm mượt mà hơn.

    Về vụ CDN thì có thể xem thêm ở bài viết này.

    EOF

    Cũng hết những cái đề cập từ đầu rồi, bài viết này với mục đích 101 để mọi người hình dung rõ hơn về thế giới web :).

  • Authorization and JWT

    Authorization and JWT

    Thực ra bài này chỉ muốn viết về JWT thôi, nhưng tiện thì sẽ nói về các loại Authorization luôn.

    Authorization và Authentication

    2 cái này cũng khác nhau:

    • Authentication
      • Được sử dụng bởi một Server khi mcần biết chính xác ai đang truy cập thông tin hoặc trang web của họ.
      • Được sử dụng bởi Client khi Client cần biết rằng máy chủ là hệ thống mà nó tuyên bố.
      • Trong Authentication, Client hoặc Machine phải chứng minh danh tính của mình với Server hoặc Client. Thông thường, xác thực bởi một máy chủ đòi hỏi phải sử dụng tên người dùng và mật khẩu. Các cách khác để xác thực có thể thông qua thẻ, quét võng mạc, nhận dạng giọng nói và dấu vân tay. Xác thực bởi khách hàng thường liên quan đến việc máy chủ cấp chứng chỉ cho khách hàng trong đó một bên thứ ba đáng tin cậy như Verisign hoặc Thawte nói rằng máy chủ đó thuộc về thực thể (như ngân hàng) mà khách hàng mong đợi. Xác thực không xác định những nhiệm vụ mà cá nhân có thể làm hoặc những tập tin cá nhân có thể nhìn thấy. Xác thực chỉ xác định và xác minh người hoặc hệ thống là ai.

    Xác thực, quá trình này xác định bạn là ai trong hệ thống. Ví dụ: login là một quá tình xác thực, bạn gửi username/password lên hệ thống, hệ thống sẽ thẩm tra nhận dạng của bạn (bằng username/password hoặc thêm một số factor nữa như trắc sinh học, token,… trong multi-factor authentication).

    • Authorization
      • Xác minh, cái này thường sau xác thực, để kiểm tra xem bạn có quyền truy cập tài nguyên không, ví dụ bạn nói với server tôi là A tôi cần truy cập tài nguyên B bằng một request:
      GET /b HTTP/1.1
Host: example.com
Authorization: Bearer i_am_A
      Như vậy server cần xác định Bearer i_am_A có phải là Authorization hợp lệ hay không và có quyền truy cập GET /b hay không.
      • Gần như 2 quá trình trên sẽ không khác nhau với các website hay application, vì vậy việc hiểu rõ khá là hữu ích.
      • Authorization cũng thường lấy kết quả của Authentication (hoặc một dẫn xuất từ việc Authentication) để xác nhận. Ví dụ sau khi đăng nhập bạn sẽ được Server gán cho một giá trị nào đó vào Session để xác nhận bạn đã đăng nhập, và dùng giá trị đó cho việc Authorization. Có một vài trường hợp khác như Basic Authentication bạn sẽ gửi Base64 của chuỗi username:password trong Authorization header, thì gần như sẽ ko thấy Authentication đâu cả.

    Vì vậy cũng có vài loại Authorization khác nhau:

    • Basic (RFC 7617, base64-encoded credentials. Đơn giản là truyền chuỗi Base64 của chuỗi username:password)
    • Bearer (RFC 6750, bearer tokens để access các resource được bảo vệ bởi OAuth 2.0)
    • Digest (RFC 7616)
    • HOBA (RFC 7486, HTTP Origin-Bound Authentication, digital-signature-based),
    • Mutual (RFC 8120,
    • AWS4-HMAC-SHA256 dùng cho AWS SDK và AWS API.

    Hiện tại thì OAuth 2.0 rất phổ biến hơn nữa nảy sinh ra nhu cầu chống làm giả token được tạo ra bởi server, đến đây thì mới xuất hiện JWT.

    JWT

    Thôi đi copy định nghĩa vậy: JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. JWT.IO allows you to decode, verify and generate JWT.

    Hình dung như này, khi bạn vào một trang web như TIKI chẳng hạn, bạn đăng nhập với Facebook hoặc tài khoản cá nhân. Vậy khi bạn đăng nhập với Facebook, TIKI sẽ kết nối đến Facebook GraphAPI với Facebook token mà bạn vừa đưa cho TIKI để verify. Khi đó bạn sẽ nhận được token từ TIKI để truy cập các resource.

    Structure

    JWT gồm 3 phần:

    • Header: Hay còn gọi là JOSE header, đề cập đến loại JWT (JWE và JWS)và kiểu mã hóa hay thuật toán mã hóa, ở hình trên là dùng RSA Signature with SHA-256
    • Payload: hay còn gọi là claims, là một đoạn data public có trong JWT, JWT thường có một vài data có thể public như
      • sub: Username hoặc UserId
      • iat: issue at, token được tạo ra lúc nào
      • exp: expire at, token hết hạn khi nào
      • iss: issuer, ai là người tạo token này ra. Ngoài ra còn có jti(JWT ID), aud(Audience), nbf(Not before), mấy cái tên này thì có thể tìm thấy ở đây này, cái này được gọi là Public Claims. Private Claims thì những cái bạn define thôi : ).
    • Signature: là phần quan trọng nhất, thì cái này lại phụ thuộc vào JOSE Header để mã hóa, tức là dùng cái thuật toán ở trên ấy, mã hóa dùng security factor như nào thì lại phụ thuộc vào JWE hay JWS.

    Xong xuôi, chúng ta sẽ dùng process base64url encode cả 3 phần rồi nối với nhau bằng dấu chấm (.).

    JWT vs Thế giới

    So với các web token khác như SWT hoặc SAML, JWT đơn giản hơn nhiều vì nó dựa trên JSON nên dễ hiểu hơn XML. Nếu chúng ta mã hóa JSON, nó sẽ trở nên nhỏ hơn kích thước so với SAML, giúp việc chuyển qua môi trường HTML và HTTP dễ dàng hơn. Về bảo mật, SWT sử dụng một khóa duy nhất, trong khi cả JWT và SAML đều sử dụng cặp khóa chung và khóa riêng để xác thực tốt hơn. Nhìn chung, JWT được sử dụng ở quy mô Internet. Điều này có nghĩa là việc xử lý trên các thiết bị của người dùng dễ dàng hơn, có thể là máy tính xách tay hoặc thiết bị di động. Ngoài khả năng tự động hóa, Mã thông báo Web JSON là một cách tuyệt vời và an toàn để truyền dữ liệu giữa nhiều bên. Việc JWT có chữ ký giúp mọi người dễ dàng xác định người gửi thông tin hơn. Tất cả bạn cần là chìa khóa chính xác.

    Một bài viết khác sẽ nói về một loại JWT của Auth0. Hãy đón chờ : )