Hong  Nhung

Hong Nhung

1659767568

11 Sai Lầm Xác Thực Hàng đầu Và Cách Khắc Phục Chúng

Bảo mật xác thực là một khía cạnh thiết yếu của phát triển ứng dụng web thường bị bỏ qua trong khi tạo sản phẩm. Tuy nhiên, nếu bạn có ý định nộp hồ sơ trực tuyến thì đó là ưu tiên hàng đầu. Trong bài viết này, tôi sẽ giải thích một số lỗi này và cách khắc phục chúng. Xin lưu ý rằng đây không phải là các vấn đề bảo mật chính mà OWASP khuyến nghị; thay vào đó, chúng là những vấn đề dễ sửa chữa mà tôi thường gặp.

Xác thực là gì?

Xác thực là quá trình xác nhận danh tính của người dùng hoặc quy trình. Khi xác thực bị vi phạm, những kẻ tấn công có thể giành quyền truy cập vào dữ liệu hoặc thông tin của người dùng, gây ra thiệt hại cho ứng dụng của bạn. Xác thực là một trong những cách mà kẻ tấn công có thể truy cập vào dữ liệu của người dùng và ứng dụng của bạn.

Khi nói đến xác thực, đây là mười một lỗi phổ biến cần tránh:

  1. Hiển thị thông báo lỗi cụ thể
  2. Tích hợp ID phiên vào một URL
  3. Xác thực biểu mẫu không chính xác
  4. Vệ sinh dạng thấp
  5. Chiến lược mật khẩu yếu
  6. Không thể sử dụng Xác thực hai yếu tố (2FA)
  7. Đặt lại mật khẩu không đúng
  8. Đăng xuất không an toàn
  9. Tấn công vũ phu
  10. Sử dụng câu hỏi bảo mật yếu
  11. Không bảo vệ được tuyến đường

Hiển thị thông báo lỗi cụ thể

Việc hiển thị một thông báo lỗi cụ thể là rất nguy hiểm vì nó có thể cho phép kẻ tấn công sử dụng phương pháp thử-và-sai tự động để xác định tên người dùng hoặc mật khẩu của người dùng.

Đây là một ví dụ sơ đồ về việc hiển thị một thông báo lỗi cụ thể. 

1

Khi xác thực một biểu mẫu trên ứng dụng web của bạn, bạn phải cẩn thận để không chỉ hiển thị một thông báo lỗi khi người dùng nhập một chi tiết không chính xác - chẳng hạn như “Mật khẩu của bạn không chính xác”. Nếu bạn hiển thị một thông báo lỗi cụ thể như vậy, kẻ tấn công sẽ nhận ra rằng địa chỉ email hoặc ID người dùng là có thật nhưng mật khẩu là sai. Điều này sẽ cho phép kẻ tấn công đề xuất mật khẩu cho người dùng đó.

Cách sửa lỗi này

  • Không bao giờ hiển thị thông báo lỗi cụ thể trên trang xác thực. Điều này cho phép kẻ tấn công biết thông tin nào bị thiếu và cho phép chúng sử dụng một cuộc tấn công bạo lực để đoán thông tin bị thiếu.
  • Hiển thị các thông báo lỗi như “chi tiết không chính xác”.

Tích hợp ID phiên vào một URL

ID phiên là một số mà máy chủ của trang web cung cấp cho một người dùng trong thời gian truy cập của người dùng đó. Cơ hội kẻ tấn công lấy được và lạm dụng mã thông báo phiên sẽ tăng lên nếu được đặt trực tiếp trong URL. Mặc dù rủi ro thấp hơn khi sử dụng HTTPS để kết nối với máy chủ web, nhưng vẫn có một mối nguy hiểm. Mặc dù URL HTTPS được mã hóa khi chuyển tiếp, chúng thường được lưu trong nhật ký máy chủ.

Dưới đây là một ví dụ sơ đồ về Tích hợp ID phiên vào URL.

2

Cách sửa lỗi này

  • Xác thực ID phiên ở phía máy chủ
  • Để tạo mã thông báo, hãy đảm bảo bạn sử dụng trình tạo ngẫu nhiên đủ an toàn.
  • Sử dụng bộ lọc để xóa ID phiên khỏi URL.

Xác thực biểu mẫu không chính xác.

Các cuộc tấn công chèn ép, rò rỉ bộ nhớ và hệ thống bị xâm nhập có thể xảy ra nếu dữ liệu được cung cấp trong đầu vào biểu mẫu không được kiểm tra hoặc định dạng đúng cách. Người dùng thường gửi mà không điền tất cả các thông tin cần thiết, vì vậy cần phải xác thực biểu mẫu của bạn để đảm bảo tất cả các thông tin yêu cầu đã được đáp ứng trước khi gửi đến máy chủ.

Cách sửa lỗi này

  • Đảm bảo rằng email có định dạng địa chỉ email.
  • Đảm bảo người dùng đã đáp ứng các tiêu chí cho biểu mẫu trước khi gửi
  • Xác thực biểu mẫu từ phụ trợ và giao diện người dùng bằng cách sử dụng thư viện hoặc khuôn khổ được cập nhật.

Một số thư viện được đề xuất mà tôi đề xuất để xác thực biểu mẫu là:

Tất cả các thư viện được liệt kê đều tốt cho việc xác thực biểu mẫu của bạn.

Vệ sinh dạng thấp 

Quá trình giữ cho đầu vào biểu mẫu của bạn sạch sẽ, được lọc và khử trùng khỏi tác nhân độc hại được gọi là quá trình khử trùng biểu mẫu. Vệ sinh đầu vào của bạn là điều bắt buộc vì nó ngăn ngừa các sai sót khi tiêm. Một biểu mẫu đầu vào được khử trùng tốt có thể ngăn chặn các cuộc tấn công sau:

Cross-site scripting (XSS): Đây là một loại lỗ hổng bảo mật thường được tìm thấy trong các ứng dụng web. Lỗ hổng này cho phép những kẻ tấn công chèn các tập lệnh phía máy khách vào các trang web mà người dùng xem. Cuộc tấn công này có thể gây ra nhiều tổn hại về bảo mật cho người dùng, chẳng hạn như chuyển hướng họ đến một trang web độc hại, buộc họ tải xuống ứng dụng phần mềm độc hại và đánh cắp dữ liệu của người dùng.

SQL injection: Những kẻ tấn công có thể can thiệp vào dữ liệu được gửi đến cơ sở dữ liệu của nó thông qua đầu vào biểu mẫu. 

Bằng cách khử trùng đầu vào biểu mẫu, bạn phải bảo vệ mã của mình và dữ liệu của người dùng khỏi tác nhân độc hại này và tất cả các lỗ hổng được liệt kê. Cá nhân tôi sử dụng DOM Purify , một thư viện làm sạch cho HTML và chuỗi, và nó có thể lọc bất kỳ thứ gì chứa HTML bẩn và ngăn chặn các cuộc tấn công XSS.

Cách sửa lỗi này

  • Sẽ dễ dàng và an toàn hơn đáng kể khi sử dụng danh sách cho phép cho các đầu vào được xác định rõ ràng như số, ngày tháng hoặc mã bưu điện. Về vấn đề đó, bạn có thể nêu rõ ràng những giá trị nào được phép và những giá trị nào không.
  • Sử dụng logic cho phép được xác định trước trong định nghĩa kiểu dữ liệu tích hợp với xác thực biểu mẫu HTML5.

Chiến lược mật khẩu yếu

Không có gì lạ khi bắt gặp một trang web không có gói mật khẩu mạnh theo thứ tự. Gần đây tôi đã thử một ứng dụng yêu cầu độ dài mật khẩu tối thiểu là năm ký tự. Khi các nhà phát triển cố gắng tìm ra sự cân bằng phù hợp giữa bảo mật và khả năng sử dụng, lỗ hổng này ngày càng phổ biến. Khi làm việc với mật khẩu, hãy đảm bảo mật khẩu bạn đề xuất cho người dùng hoặc mật khẩu mà người dùng tạo là hỗn hợp các ký hiệu, số và chữ cái viết hoa hỗn hợp. Tránh các kế hoạch mật khẩu yếu.

Cách sửa lỗi này

  • Yêu cầu người dùng nhập tối thiểu 12 hoặc 8 ký tự hoặc dài hơn.
  • Nên tránh sử dụng mật khẩu kết hợp tên người dùng hoặc tên công ty để bảo mật và khả năng sử dụng.
  • Chữ hoa và chữ thường nên được trộn lẫn.
  • Sử dụng thư viện để tính toán độ mạnh của mật khẩu, thận trọng khi chọn và kiểm tra các phụ thuộc và khả năng bảo trì tối thiểu.
  • Khi một người có hồ sơ công khai, hãy sử dụng tên hiển thị khác và tránh sử dụng địa chỉ email của người dùng làm tên hiển thị vì điều này mời spam.

Không thể sử dụng Xác thực hai yếu tố

Một sai lầm phổ biến khác mà tôi thấy với các cơ chế xác thực web là chúng không có bất kỳ biện pháp an toàn bổ sung nào. Xác thực hai yếu tố hiếm khi được các nhà phát triển sử dụng, đặc biệt là đối với các tài khoản hàng đầu. Xác thực hai yếu tố giúp bổ sung lớp bảo vệ thứ hai cho ứng dụng của bạn. Xác thực hai yếu tố rất quan trọng đối với bảo mật web vì nó ngay lập tức loại bỏ các nguy cơ về thông tin xác thực bị xâm phạm. Khi một mật khẩu bị bẻ khóa, bị đoán hoặc thậm chí bị nhiễm phần mềm độc hại, thì việc cấp quyền truy cập cho kẻ xâm nhập mà không có sự chấp thuận ở yếu tố xác thực thứ hai là không còn đủ.

Xác thực hai yếu tố là một lớp bảo mật bổ sung được thêm vào trang xác thực. Ví dụ về xác thực hai yếu tố này là SMS, email và OTP.

Đây là một ví dụ sơ đồ về xác thực hai yếu tố 

3

Cách triển khai xác thực hai yếu tố

Có nhiều cách khác nhau để sử dụng mã hóa 2FA. Mã thông báo RSA, trình tạo mã như Google Authenticator và Duo và gửi văn bản SMS mã một lần là tất cả các tùy chọn để triển khai công nghệ 2FA.

Đặt lại mật khẩu không đúng

Điều này không thường xuyên xảy ra, nhưng thỉnh thoảng, tôi thấy một ứng dụng web có khả năng này được triển khai không chính xác. Điều này thường là do mật khẩu của người dùng đã được gửi cho họ qua email hoặc mã thông báo được sử dụng để đặt lại mật khẩu không đủ mạnh. Việc gửi lại mật khẩu bản rõ cho người dùng cuối là một vấn đề khác ảnh hưởng đến việc đặt lại mật khẩu. Điều này thật tồi tệ vì nhiều lý do khác nhau, một trong số đó là mật khẩu được gửi qua email, được coi là không an toàn. Điều này có thể có nghĩa là mật khẩu được lưu trữ trong cơ sở dữ liệu mà không có đủ băm hoặc ở định dạng có thể bị đảo ngược, như base64.

Hashing  là một kỹ thuật được sử dụng để xác minh hoặc xác nhận chất lượng của nhiều loại đầu vào khác nhau. Trong các hệ thống xác thực, nó chủ yếu được sử dụng để ngăn chặn việc lưu trữ các mật khẩu văn bản rõ ràng, và Hashing khiến những kẻ tấn công vô cùng khó khăn trong việc giải mã các mật khẩu đã được lưu trữ.

Base64: Base64 là một phương pháp chuyển đổi dữ liệu nhị phân thành văn bản. Phương pháp này thường được sử dụng để gửi thông tin dựa trên nội dung qua Internet.

Cách sửa lỗi này

  • Luôn mã hóa mật khẩu người dùng trước khi lưu trữ, không lưu trữ ở dạng thô.
  • Chỉ gửi email giao dịch sau khi xác thực và xác minh địa chỉ email bằng cách kiểm tra các ký tự hợp lệ và gửi liên kết xác minh có mã thông báo.

Đăng xuất không an toàn

Đây là một lỗ hổng khác có thể gây ra sự tàn phá lớn cho một ứng dụng. Nó cũng cần thiết để cung cấp cho người dùng của bạn một cách an toàn để đăng xuất để các phiên của họ không thể bị chiếm đoạt. Nếu bạn đang lưu trữ số nhận dạng phiên ở phía máy chủ, phương pháp đăng xuất sẽ làm mất hiệu lực của nó và xóa cookie phiên trong trình duyệt. Điều này ngăn những kẻ tấn công có thể đánh cắp cookie phiên và sau đó sử dụng chúng để bắt đầu một phiên mới.

Cách sửa lỗi này

  • Khi người dùng đăng xuất, hãy xóa cookie phiên của trình duyệt và làm mất hiệu lực nhận dạng phiên nếu nó đang được lưu trữ trên máy chủ.
  • Trong quá trình đăng xuất, phiên người dùng và mã thông báo xác thực phải được vô hiệu hóa một cách chính xác.

Tấn công vũ phu

Brute force là một kỹ thuật hack được sử dụng để tìm ra thông tin đăng nhập của người dùng bằng cách thử nhiều thông tin đăng nhập có thể có. Trong cuộc tấn công này, tin tặc cố gắng đoán mật khẩu để vượt qua xác thực cho một tài khoản. Sử dụng các tập lệnh thử nhiều mật khẩu thường dùng từ từ điển và hàng triệu mật khẩu bị rò rỉ từ các lần vi phạm dữ liệu trước đó, những lần thử này có cơ hội thành công cao hơn.

Cách sửa lỗi này

  • Hạn chế các nỗ lực đăng nhập vào một địa chỉ hoặc dải IP xác định bằng cách chặn quyền truy cập vào URL xác thực.
  • Không sử dụng thuật ngữ nào từ từ điển bằng bất kỳ ngôn ngữ nào. Thay vì sử dụng các từ, tốt hơn là sử dụng các chuỗi ký tự ngẫu nhiên.
  • Chặn các địa chỉ IP độc hại bằng CAPTCHAS.
  • Theo dõi các lần đăng nhập thất bại của người dùng và khóa tài khoản.

Sử dụng câu hỏi bảo mật không đầy đủ

Một câu hỏi bảo mật hoặc từ dễ nhớ cũng có thể hỗ trợ trong việc bảo vệ chống lại các cuộc tấn công tự động. Tôi đã gặp phải các câu hỏi bảo mật yếu có câu trả lời có thể đoán trước, cho phép kẻ tấn công đề xuất hoặc đoán câu trả lời và có được quyền truy cập vào dữ liệu của người dùng.

Dưới đây là một số câu hỏi bảo mật phổ biến mà tôi đã gặp:

  • Bạn sinh ra ở thành phố nào?
  • Ngày sinh của bạn là gì?
  • bạn đã học trường trung học phổ thông nào?
  • Tên thời con gái của mẹ bạn là gì?

Tránh tất cả những câu hỏi này vì tin tặc có thể đoán chúng do một số thông tin trên Google hoặc các hồ sơ trực tuyến khác của chúng tôi.

Cách sửa lỗi này

  • Đề xuất những câu hỏi người dùng dễ nhớ nhưng kẻ tấn công khó đề xuất
  • Lưu trữ câu trả lời bằng thuật toán băm an toàn như Bcrypt. Bcrypt là một thuật toán được sử dụng để băm và xác minh mật khẩu. Nó giúp giảm nguy cơ tội phạm mạng tấn công ứng dụng của bạn thông qua mật khẩu.

Không bảo vệ các tuyến đường

Một lỗi khác mà tôi đã thấy các nhà phát triển mắc phải khi nói đến xác thực là "không bảo vệ được tuyến đường." Điều quan trọng là phải bảo mật các tuyến đường cụ thể trong ứng dụng của bạn khỏi những người dùng không được xác thực, vì điều này sẽ ngăn những người dùng không xác định truy cập vào một số dữ liệu riêng tư của ứng dụng của bạn.

Cách sửa lỗi này

  • Bảo vệ tuyến đường bạn muốn người dùng chưa xác thực truy cập.
  • Nếu người dùng đang cố gắng truy cập vào một tuyến đường cụ thể, hãy chuyển hướng họ đến trang đăng nhập / đăng ký nếu chúng chưa được xác thực

Sự kết luận

Khi triển khai xác thực trên trang web của mình, bạn phải hết sức thận trọng với tư cách là nhà phát triển vì một số phương pháp có thể gây hại cho chương trình của bạn và mở ra cánh cửa cho những kẻ tấn công chiếm quyền kiểm soát dữ liệu của người dùng và ứng dụng. Hy vọng rằng, bài viết này đã chỉ ra những lỗi như vậy và đưa ra lời khuyên về cách khắc phục chúng.

Liên kết: https://blog.openreplay.com/11-authentication-mistakes-and-how-to-fix-them

#authentication

What is GEEK

Buddha Community

11 Sai Lầm Xác Thực Hàng đầu Và Cách Khắc Phục Chúng
Kaia  Schmitt

Kaia Schmitt

1659817260

SDK for Connecting to AWS IoT From A Device using Embedded C

AWS IoT Device SDK for Embedded C

Overview

The AWS IoT Device SDK for Embedded C (C-SDK) is a collection of C source files under the MIT open source license that can be used in embedded applications to securely connect IoT devices to AWS IoT Core. It contains MQTT client, HTTP client, JSON Parser, AWS IoT Device Shadow, AWS IoT Jobs, and AWS IoT Device Defender libraries. This SDK is distributed in source form, and can be built into customer firmware along with application code, other libraries and an operating system (OS) of your choice. These libraries are only dependent on standard C libraries, so they can be ported to various OS's - from embedded Real Time Operating Systems (RTOS) to Linux/Mac/Windows. You can find sample usage of C-SDK libraries on POSIX systems using OpenSSL (e.g. Linux demos in this repository), and on FreeRTOS using mbedTLS (e.g. FreeRTOS demos in FreeRTOS repository).

For the latest release of C-SDK, please see the section for Releases and Documentation.

C-SDK includes libraries that are part of the FreeRTOS 202012.01 LTS release. Learn more about the FreeRTOS 202012.01 LTS libraries by clicking here.

License

The C-SDK libraries are licensed under the MIT open source license.

Features

C-SDK simplifies access to various AWS IoT services. C-SDK has been tested to work with AWS IoT Core and an open source MQTT broker to ensure interoperability. The AWS IoT Device Shadow, AWS IoT Jobs, and AWS IoT Device Defender libraries are flexible to work with any MQTT client and JSON parser. The MQTT client and JSON parser libraries are offered as choices without being tightly coupled with the rest of the SDK. C-SDK contains the following libraries:

coreMQTT

The coreMQTT library provides the ability to establish an MQTT connection with a broker over a customer-implemented transport layer, which can either be a secure channel like a TLS session (mutually authenticated or server-only authentication) or a non-secure channel like a plaintext TCP connection. This MQTT connection can be used for performing publish operations to MQTT topics and subscribing to MQTT topics. The library provides a mechanism to register customer-defined callbacks for receiving incoming PUBLISH, acknowledgement and keep-alive response events from the broker. The library has been refactored for memory optimization and is compliant with the MQTT 3.1.1 standard. It has no dependencies on any additional libraries other than the standard C library, a customer-implemented network transport interface, and optionally a customer-implemented platform time function. The refactored design embraces different use-cases, ranging from resource-constrained platforms using only QoS 0 MQTT PUBLISH messages to resource-rich platforms using QoS 2 MQTT PUBLISH over TLS connections.

See memory requirements for the latest release here.

coreHTTP

The coreHTTP library provides the ability to establish an HTTP connection with a server over a customer-implemented transport layer, which can either be a secure channel like a TLS session (mutually authenticated or server-only authentication) or a non-secure channel like a plaintext TCP connection. The HTTP connection can be used to make "GET" (include range requests), "PUT", "POST" and "HEAD" requests. The library provides a mechanism to register a customer-defined callback for receiving parsed header fields in an HTTP response. The library has been refactored for memory optimization, and is a client implementation of a subset of the HTTP/1.1 standard.

See memory requirements for the latest release here.

coreJSON

The coreJSON library is a JSON parser that strictly enforces the ECMA-404 JSON standard. It provides a function to validate a JSON document, and a function to search for a key and return its value. A search can descend into nested structures using a compound query key. A JSON document validation also checks for illegal UTF8 encodings and illegal Unicode escape sequences.

See memory requirements for the latest release here.

corePKCS11

The corePKCS11 library is an implementation of the PKCS #11 interface (API) that makes it easier to develop applications that rely on cryptographic operations. Only a subset of the PKCS #11 v2.4 standard has been implemented, with a focus on operations involving asymmetric keys, random number generation, and hashing.

The Cryptoki or PKCS #11 standard defines a platform-independent API to manage and use cryptographic tokens. The name, "PKCS #11", is used interchangeably to refer to the API itself and the standard which defines it.

The PKCS #11 API is useful for writing software without taking a dependency on any particular implementation or hardware. By writing against the PKCS #11 standard interface, code can be used interchangeably with multiple algorithms, implementations and hardware.

Generally vendors for secure cryptoprocessors such as Trusted Platform Module (TPM), Hardware Security Module (HSM), Secure Element, or any other type of secure hardware enclave, distribute a PKCS #11 implementation with the hardware. The purpose of corePKCS11 mock is therefore to provide a PKCS #11 implementation that allows for rapid prototyping and development before switching to a cryptoprocessor specific PKCS #11 implementation in production devices.

Since the PKCS #11 interface is defined as part of the PKCS #11 specification replacing corePKCS11 with another implementation should require little porting effort, as the interface will not change. The system tests distributed in corePKCS11 repository can be leveraged to verify the behavior of a different implementation is similar to corePKCS11.

See memory requirements for the latest release here.

AWS IoT Device Shadow

The AWS IoT Device Shadow library enables you to store and retrieve the current state one or more shadows of every registered device. A device’s shadow is a persistent, virtual representation of your device that you can interact with from AWS IoT Core even if the device is offline. The device state is captured in its "shadow" is represented as a JSON document. The device can send commands over MQTT to get, update and delete its latest state as well as receive notifications over MQTT about changes in its state. The device’s shadow(s) are uniquely identified by the name of the corresponding "thing", a representation of a specific device or logical entity on the AWS Cloud. See Managing Devices with AWS IoT for more information on IoT "thing". This library supports named shadows, a feature of the AWS IoT Device Shadow service that allows you to create multiple shadows for a single IoT device. More details about AWS IoT Device Shadow can be found in AWS IoT documentation.

The AWS IoT Device Shadow library has no dependencies on additional libraries other than the standard C library. It also doesn’t have any platform dependencies, such as threading or synchronization. It can be used with any MQTT library and any JSON library (see demos with coreMQTT and coreJSON).

See memory requirements for the latest release here.

AWS IoT Jobs

The AWS IoT Jobs library enables you to interact with the AWS IoT Jobs service which notifies one or more connected devices of a pending “Job”. A Job can be used to manage your fleet of devices, update firmware and security certificates on your devices, or perform administrative tasks such as restarting devices and performing diagnostics. For documentation of the service, please see the AWS IoT Developer Guide. Interactions with the Jobs service use the MQTT protocol. This library provides an API to compose and recognize the MQTT topic strings used by the Jobs service.

The AWS IoT Jobs library has no dependencies on additional libraries other than the standard C library. It also doesn’t have any platform dependencies, such as threading or synchronization. It can be used with any MQTT library and any JSON library (see demos with libmosquitto and coreJSON).

See memory requirements for the latest release here.

AWS IoT Device Defender

The AWS IoT Device Defender library enables you to interact with the AWS IoT Device Defender service to continuously monitor security metrics from devices for deviations from what you have defined as appropriate behavior for each device. If something doesn’t look right, AWS IoT Device Defender sends out an alert so you can take action to remediate the issue. More details about Device Defender can be found in AWS IoT Device Defender documentation. This library supports custom metrics, a feature that helps you monitor operational health metrics that are unique to your fleet or use case. For example, you can define a new metric to monitor the memory usage or CPU usage on your devices.

The AWS IoT Device Defender library has no dependencies on additional libraries other than the standard C library. It also doesn’t have any platform dependencies, such as threading or synchronization. It can be used with any MQTT library and any JSON library (see demos with coreMQTT and coreJSON).

See memory requirements for the latest release here.

AWS IoT Over-the-air Update

The AWS IoT Over-the-air Update (OTA) library enables you to manage the notification of a newly available update, download the update, and perform cryptographic verification of the firmware update. Using the OTA library, you can logically separate firmware updates from the application running on your devices. You can also use the library to send other files (e.g. images, certificates) to one or more devices registered with AWS IoT. More details about OTA library can be found in AWS IoT Over-the-air Update documentation.

The AWS IoT Over-the-air Update library has a dependency on coreJSON for parsing of JSON job document and tinyCBOR for decoding encoded data streams, other than the standard C library. It can be used with any MQTT library, HTTP library, and operating system (e.g. Linux, FreeRTOS) (see demos with coreMQTT and coreHTTP over Linux).

See memory requirements for the latest release here.

AWS IoT Fleet Provisioning

The AWS IoT Fleet Provisioning library enables you to interact with the AWS IoT Fleet Provisioning MQTT APIs in order to provison IoT devices without preexisting device certificates. With AWS IoT Fleet Provisioning, devices can securely receive unique device certificates from AWS IoT when they connect for the first time. For an overview of all provisioning options offered by AWS IoT, see device provisioning documentation. For details about Fleet Provisioning, refer to the AWS IoT Fleet Provisioning documentation.

See memory requirements for the latest release here.

AWS SigV4

The AWS SigV4 library enables you to sign HTTP requests with Signature Version 4 Signing Process. Signature Version 4 (SigV4) is the process to add authentication information to HTTP requests to AWS services. For security, most requests to AWS must be signed with an access key. The access key consists of an access key ID and secret access key.

See memory requirements for the latest release here.

backoffAlgorithm

The backoffAlgorithm library is a utility library to calculate backoff period using an exponential backoff with jitter algorithm for retrying network operations (like failed network connection with server). This library uses the "Full Jitter" strategy for the exponential backoff with jitter algorithm. More information about the algorithm can be seen in the Exponential Backoff and Jitter AWS blog.

Exponential backoff with jitter is typically used when retrying a failed connection or network request to the server. An exponential backoff with jitter helps to mitigate the failed network operations with servers, that are caused due to network congestion or high load on the server, by spreading out retry requests across multiple devices attempting network operations. Besides, in an environment with poor connectivity, a client can get disconnected at any time. A backoff strategy helps the client to conserve battery by not repeatedly attempting reconnections when they are unlikely to succeed.

The backoffAlgorithm library has no dependencies on libraries other than the standard C library.

See memory requirements for the latest release here.

Sending metrics to AWS IoT

When establishing a connection with AWS IoT, users can optionally report the Operating System, Hardware Platform and MQTT client version information of their device to AWS. This information can help AWS IoT provide faster issue resolution and technical support. If users want to report this information, they can send a specially formatted string (see below) in the username field of the MQTT CONNECT packet.

Format

The format of the username string with metrics is:

<Actual_Username>?SDK=<OS_Name>&Version=<OS_Version>&Platform=<Hardware_Platform>&MQTTLib=<MQTT_Library_name>@<MQTT_Library_version>

Where

  • is the actual username used for authentication, if username and password are used for authentication. When username and password based authentication is not used, this is an empty value.
  • is the Operating System the application is running on (e.g. Ubuntu)
  • is the version number of the Operating System (e.g. 20.10)
  • is the Hardware Platform the application is running on (e.g. RaspberryPi)
  • is the MQTT Client library being used (e.g. coreMQTT)
  • is the version of the MQTT Client library being used (e.g. 1.1.0)

Example

  • Actual_Username = “iotuser”, OS_Name = Ubuntu, OS_Version = 20.10, Hardware_Platform_Name = RaspberryPi, MQTT_Library_Name = coremqtt, MQTT_Library_version = 1.1.0. If username is not used, then “iotuser” can be removed.
/* Username string:
 * iotuser?SDK=Ubuntu&Version=20.10&Platform=RaspberryPi&MQTTLib=coremqtt@1.1.0
 */

#define OS_NAME                   "Ubuntu"
#define OS_VERSION                "20.10"
#define HARDWARE_PLATFORM_NAME    "RaspberryPi"
#define MQTT_LIB                  "coremqtt@1.1.0"

#define USERNAME_STRING           "iotuser?SDK=" OS_NAME "&Version=" OS_VERSION "&Platform=" HARDWARE_PLATFORM_NAME "&MQTTLib=" MQTT_LIB
#define USERNAME_STRING_LENGTH    ( ( uint16_t ) ( sizeof( USERNAME_STRING ) - 1 ) )

MQTTConnectInfo_t connectInfo;
connectInfo.pUserName = USERNAME_STRING;
connectInfo.userNameLength = USERNAME_STRING_LENGTH;
mqttStatus = MQTT_Connect( pMqttContext, &connectInfo, NULL, CONNACK_RECV_TIMEOUT_MS, pSessionPresent );

Versioning

C-SDK releases will now follow a date based versioning scheme with the format YYYYMM.NN, where:

  • Y represents the year.
  • M represents the month.
  • N represents the release order within the designated month (00 being the first release).

For example, a second release in June 2021 would be 202106.01. Although the SDK releases have moved to date-based versioning, each library within the SDK will still retain semantic versioning. In semantic versioning, the version number itself (X.Y.Z) indicates whether the release is a major, minor, or point release. You can use the semantic version of a library to assess the scope and impact of a new release on your application.

Releases and Documentation

All of the released versions of the C-SDK libraries are available as git tags. For example, the last release of the v3 SDK version is available at tag 3.1.2.

202108.00

API documentation of 202108.00 release

This release introduces the refactored AWS IoT Fleet Provisioning library and the new AWS SigV4 library.

Additionally, this release brings minor version updates in the AWS IoT Over-the-Air Update and corePKCS11 libraries.

202103.00

API documentation of 202103.00 release

This release includes a major update to the APIs of the AWS IoT Over-the-air Update library.

Additionally, AWS IoT Device Shadow library introduces a minor update by adding support for named shadow, a feature of the AWS IoT Device Shadow service that allows you to create multiple shadows for a single IoT device. AWS IoT Jobs library introduces a minor update by introducing macros for $next job ID and compile-time generation of topic strings. AWS IoT Device Defender library introduces a minor update that adds macros to API for custom metrics feature of AWS IoT Device Defender service.

corePKCS11 also introduces a patch update by removing the pkcs11configPAL_DESTROY_SUPPORTED config and mbedTLS platform abstraction layer of DestroyObject. Lastly, no code changes are introduced for backoffAlgorithm, coreHTTP, coreMQTT, and coreJSON; however, patch updates are made to improve documentation and CI.

202012.01

API documentation of 202012.01 release

This release includes AWS IoT Over-the-air Update(Release Candidate), backoffAlgorithm, and PKCS #11 libraries. Additionally, there is a major update to the coreJSON and coreHTTP APIs. All libraries continue to undergo code quality checks (e.g. MISRA-C compliance), and Coverity static analysis. In addition, all libraries except AWS IoT Over-the-air Update and backoffAlgorithm undergo validation of memory safety with the C Bounded Model Checker (CBMC) automated reasoning tool.

202011.00

API documentation of 202011.00 release

This release includes refactored HTTP client, AWS IoT Device Defender, and AWS IoT Jobs libraries. Additionally, there is a major update to the coreJSON API. All libraries continue to undergo code quality checks (e.g. MISRA-C compliance), Coverity static analysis, and validation of memory safety with the C Bounded Model Checker (CBMC) automated reasoning tool.

202009.00

API documentation of 202009.00 release

This release includes refactored MQTT, JSON Parser, and AWS IoT Device Shadow libraries for optimized memory usage and modularity. These libraries are included in the SDK via Git submoduling. These libraries have gone through code quality checks including verification that no function has a GNU Complexity score over 8, and checks against deviations from mandatory rules in the MISRA coding standard. Deviations from the MISRA C:2012 guidelines are documented under MISRA Deviations. These libraries have also undergone both static code analysis from Coverity static analysis, and validation of memory safety and data structure invariance through the CBMC automated reasoning tool.

If you are upgrading from v3.x API of the C-SDK to the 202009.00 release, please refer to Migration guide from v3.1.2 to 202009.00 and newer releases. If you are using the C-SDK v4_beta_deprecated branch, note that we will continue to maintain this branch for critical bug fixes and security patches but will not add new features to it. See the C-SDK v4_beta_deprecated branch README for additional details.

v3.1.2

Details available here.

Porting Guide for 202009.00 and newer releases

All libraries depend on the ISO C90 standard library and additionally on the stdint.h library for fixed-width integers, including uint8_t, int8_t, uint16_t, uint32_t and int32_t, and constant macros like UINT16_MAX. If your platform does not support the stdint.h library, definitions of the mentioned fixed-width integer types will be required for porting any C-SDK library to your platform.

Porting coreMQTT

Guide for porting coreMQTT library to your platform is available here.

Porting coreHTTP

Guide for porting coreHTTP library is available here.

Porting AWS IoT Device Shadow

Guide for porting AWS IoT Device Shadow library is available here.

Porting AWS IoT Device Defender

Guide for porting AWS IoT Device Defender library is available here.

Porting AWS IoT Over-the-air Update

Guide for porting OTA library to your platform is available here.

Migration guide from v3.1.2 to 202009.00 and newer releases

MQTT Migration

Migration guide for MQTT library is available here.

Shadow Migration

Migration guide for Shadow library is available here.

Jobs Migration

Migration guide for Jobs library is available here.

Branches

main branch

The main branch hosts the continuous development of the AWS IoT Embedded C SDK (C-SDK) libraries. Please be aware that the development at the tip of the main branch is continuously in progress, and may have bugs. Consider using the tagged releases of the C-SDK for production ready software.

v4_beta_deprecated branch (formerly named v4_beta)

The v4_beta_deprecated branch contains a beta version of the C-SDK libraries, which is now deprecated. This branch was earlier named as v4_beta, and was renamed to v4_beta_deprecated. The libraries in this branch will not be released. However, critical bugs will be fixed and tested. No new features will be added to this branch.

Getting Started

Cloning

This repository uses Git Submodules to bring in the C-SDK libraries (eg, MQTT ) and third-party dependencies (eg, mbedtls for POSIX platform transport layer). Note: If you download the ZIP file provided by GitHub UI, you will not get the contents of the submodules (The ZIP file is also not a valid git repository). If you download from the 202012.00 Release Page page, you will get the entire repository (including the submodules) in the ZIP file, aws-iot-device-sdk-embedded-c-202012.00.zip. To clone the latest commit to main branch using HTTPS:

git clone --recurse-submodules https://github.com/aws/aws-iot-device-sdk-embedded-C.git

Using SSH:

git clone --recurse-submodules git@github.com:aws/aws-iot-device-sdk-embedded-C.git

If you have downloaded the repo without using the --recurse-submodules argument, you need to run:

git submodule update --init --recursive

When building with CMake, submodules are also recursively cloned automatically. However, -DBUILD_CLONE_SUBMODULES=0 can be passed as a CMake flag to disable this functionality. This is useful when you'd like to build CMake while using a different commit from a submodule.

Configuring Demos

The libraries in this SDK are not dependent on any operating system. However, the demos for the libraries in this SDK are built and tested on a Linux platform. The demos build with CMake, a cross-platform build tool.

Prerequisites

  • CMake 3.2.0 or any newer version for utilizing the build system of the repository.
  • C90 compiler such as gcc
    • Due to the use of mbedtls in corePKCS11, a C99 compiler is required if building the PKCS11 demos or the CMake install target.
  • Although not a part of the ISO C90 standard, stdint.h is required for fixed-width integer types that include uint8_t, int8_t, uint16_t, uint32_t and int32_t, and constant macros like UINT16_MAX, while stdbool.h is required for boolean parameters in coreMQTT. For compilers that do not provide these header files, coreMQTT provides the files stdint.readme and stdbool.readme, which can be renamed to stdint.h and stdbool.h, respectively, to provide the required type definitions.
  • A supported operating system. The ports provided with this repo are expected to work with all recent versions of the following operating systems, although we cannot guarantee the behavior on all systems.
    • Linux system with POSIX sockets, threads, RT, and timer APIs. (We have tested on Ubuntu 18.04).

Build Dependencies

The follow table shows libraries that need to be installed in your system to run certain demos. If a dependency is not installed and cannot be built from source, demos that require that dependency will be excluded from the default all target.

DependencyVersionUsage
OpenSSL1.1.0 or laterAll TLS demos and tests with the exception of PKCS11
Mosquitto Client1.4.10 or laterAWS IoT Jobs Mosquitto demo

AWS IoT Account Setup

You need to setup an AWS account and access the AWS IoT console for running the AWS IoT Device Shadow library, AWS IoT Device Defender library, AWS IoT Jobs library, AWS IoT OTA library and coreHTTP S3 download demos. Also, the AWS account can be used for running the MQTT mutual auth demo against AWS IoT broker. Note that running the AWS IoT Device Defender, AWS IoT Jobs and AWS IoT Device Shadow library demos require the setup of a Thing resource for the device running the demo. Follow the links to:

The MQTT Mutual Authentication and AWS IoT Shadow demos include example AWS IoT policy documents to run each respective demo with AWS IoT. You may use the MQTT Mutual auth and Shadow example policies by replacing [AWS_REGION] and [AWS_ACCOUNT_ID] with the strings of your region and account identifier. While the IoT Thing name and MQTT client identifier do not need to match for the demos to run, the example policies have the Thing name and client identifier identical as per AWS IoT best practices.

It can be very helpful to also have the AWS Command Line Interface tooling installed.

Configuring mutual authentication demos of MQTT and HTTP

You can pass the following configuration settings as command line options in order to run the mutual auth demos. Make sure to run the following command in the root directory of the C-SDK:

## optionally find your-aws-iot-endpoint from the command line
aws iot describe-endpoint --endpoint-type iot:Data-ATS
cmake -S . -Bbuild
-DAWS_IOT_ENDPOINT="<your-aws-iot-endpoint>" -DCLIENT_CERT_PATH="<your-client-certificate-path>" -DCLIENT_PRIVATE_KEY_PATH="<your-client-private-key-path>" 

In order to set these configurations manually, edit demo_config.h in demos/mqtt/mqtt_demo_mutual_auth/ and demos/http/http_demo_mutual_auth/ to #define the following:

  • Set AWS_IOT_ENDPOINT to your custom endpoint. This is found on the Settings page of the AWS IoT Console and has a format of ABCDEFG1234567.iot.<aws-region>.amazonaws.com where <aws-region> can be an AWS region like us-east-2.
    • Optionally, it can also be found with the AWS CLI command aws iot describe-endpoint --endpoint-type iot:Data-ATS.
  • Set CLIENT_CERT_PATH to the path of the client certificate downloaded when setting up the device certificate in AWS IoT Account Setup.
  • Set CLIENT_PRIVATE_KEY_PATH to the path of the private key downloaded when setting up the device certificate in AWS IoT Account Setup.

It is possible to configure ROOT_CA_CERT_PATH to any PEM-encoded Root CA Certificate. However, this is optional because CMake will download and set it to AmazonRootCA1.pem when unspecified.

Configuring AWS IoT Device Defender and AWS IoT Device Shadow demos

To build the AWS IoT Device Defender and AWS IoT Device Shadow demos, you can pass the following configuration settings as command line options. Make sure to run the following command in the root directory of the C-SDK:

cmake -S . -Bbuild -DAWS_IOT_ENDPOINT="<your-aws-iot-endpoint>" -DROOT_CA_CERT_PATH="<your-path-to-amazon-root-ca>" -DCLIENT_CERT_PATH="<your-client-certificate-path>" -DCLIENT_PRIVATE_KEY_PATH="<your-client-private-key-path>" -DTHING_NAME="<your-registered-thing-name>"

An Amazon Root CA certificate can be downloaded from here.

In order to set these configurations manually, edit demo_config.h in the demo folder to #define the following:

  • Set AWS_IOT_ENDPOINT to your custom endpoint. This is found on the Settings page of the AWS IoT Console and has a format of ABCDEFG1234567.iot.us-east-2.amazonaws.com.
  • Set ROOT_CA_CERT_PATH to the path of the root CA certificate downloaded when setting up the device certificate in AWS IoT Account Setup.
  • Set CLIENT_CERT_PATH to the path of the client certificate downloaded when setting up the device certificate in AWS IoT Account Setup.
  • Set CLIENT_PRIVATE_KEY_PATH to the path of the private key downloaded when setting up the device certificate in AWS IoT Account Setup.
  • Set THING_NAME to the name of the Thing created in AWS IoT Account Setup.

Configuring the AWS IoT Fleet Provisioning demo

To build the AWS IoT Fleet Provisioning Demo, you can pass the following configuration settings as command line options. Make sure to run the following command in the root directory of the C-SDK:

cmake -S . -Bbuild -DAWS_IOT_ENDPOINT="<your-aws-iot-endpoint>" -DROOT_CA_CERT_PATH="<your-path-to-amazon-root-ca>" -DCLAIM_CERT_PATH="<your-claim-certificate-path>" -DCLAIM_PRIVATE_KEY_PATH="<your-claim-private-key-path>" -DPROVISIONING_TEMPLATE_NAME="<your-template-name>" -DDEVICE_SERIAL_NUMBER="<your-serial-number>"

An Amazon Root CA certificate can be downloaded from here.

To create a provisioning template and claim credentials, sign into your AWS account and visit here. Make sure to enable the "Use the AWS IoT registry to manage your device fleet" option. Once you have created the template and credentials, modify the claim certificate's policy to match the sample policy.

In order to set these configurations manually, edit demo_config.h in the demo folder to #define the following:

  • Set AWS_IOT_ENDPOINT to your custom endpoint. This is found on the Settings page of the AWS IoT Console and has a format of ABCDEFG1234567.iot.us-east-2.amazonaws.com.
  • Set ROOT_CA_CERT_PATH to the path of the root CA certificate downloaded when setting up the device certificate in AWS IoT Account Setup.
  • Set CLAIM_CERT_PATH to the path of the claim certificate downloaded when setting up the template and claim credentials.
  • Set CLAIM_PRIVATE_KEY_PATH to the path of the private key downloaded when setting up the template and claim credentials.
  • Set PROVISIONING_TEMPLATE_NAME to the name of the provisioning template created.
  • Set DEVICE_SERIAL_NUMBER to an arbitrary string representing a device identifier.

Configuring the S3 demos

You can pass the following configuration settings as command line options in order to run the S3 demos. Make sure to run the following command in the root directory of the C-SDK:

cmake -S . -Bbuild -DS3_PRESIGNED_GET_URL="s3-get-url" -DS3_PRESIGNED_PUT_URL="s3-put-url"

S3_PRESIGNED_PUT_URL is only needed for the S3 upload demo.

In order to set these configurations manually, edit demo_config.h in demos/http/http_demo_s3_download_multithreaded, and demos/http/http_demo_s3_upload to #define the following:

  • Set S3_PRESIGNED_GET_URL to a S3 presigned URL with GET access.
  • Set S3_PRESIGNED_PUT_URL to a S3 presigned URL with PUT access.

You can generate the presigned urls using demos/http/common/src/presigned_urls_gen.py. More info can be found here.

Configure S3 Download HTTP Demo using SigV4 Library:

Refer this demos/http/http_demo_s3_download/README.md to follow the steps needed to configure and run the S3 Download HTTP Demo using SigV4 Library that generates the authorization HTTP header needed to authenticate the HTTP requests send to S3.

Setup for AWS IoT Jobs demo

  1. The demo requires the Linux platform to contain curl and libmosquitto. On a Debian platform, these dependencies can be installed with:
    apt install curl libmosquitto-dev

If the platform does not contain the libmosquitto library, the demo will build the library from source.

libmosquitto 1.4.10 or any later version of the first major release is required to run this demo.

  1. A job that specifies the URL to download for the demo needs to be created on the AWS account for the Thing resource that will be used by the demo.
    The job can be created directly from the AWS IoT console or using the aws cli tool.

The following creates a job that specifies a Linux Kernel link for downloading.

 aws iot create-job \
        --job-id 'job_1' \
        --targets arn:aws:iot:us-west-2:<account-id>:thing/<thing-name> \
        --document '{"url":"https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.5.tar.xz"}'

Prerequisites for the AWS Over-The-Air Update (OTA) demos

  1. To perform a successful OTA update, you need to complete the prerequisites mentioned here.
  2. A code signing certificate is required to authenticate the update. A code signing certificate based on the SHA-256 ECDSA algorithm will work with the current demos. An example of how to generate this kind of certificate can be found here.

Scheduling an OTA Update Job

After you build and run the initial executable you will have to create another executable and schedule an OTA update job with this image.

  1. Increase the version of the application by setting macro APP_VERSION_BUILD in demos/ota/ota_demo_core_[mqtt/http]/demo_config.h to a different version than what is running.
  2. Rebuild the application using the build steps below into a different directory, say build-dir-2.
  3. Rename the demo executable to reflect the change, e.g. mv ota_demo_core_mqtt ota_demo_core_mqtt2
  4. Create an OTA job:
    1. Go to the AWS IoT Core console.
    2. Manage → Jobs → Create → Create a FreeRTOS OTA update job → Select the corresponding name for your device from the thing list.
    3. Sign a new firmware → Create a new profile → Select any SHA-ECDSA signing platform → Upload the code signing certificate(from prerequisites) and provide its path on the device.
    4. Select the image → Select the bucket you created during the prerequisite steps → Upload the binary build-dir-2/bin/ota_demo2.
    5. The path on device should be the absolute path to place the executable and the binary name: e.g. /home/ubuntu/aws-iot-device-sdk-embedded-C-staging/build-dir/bin/ota_demo_core_mqtt2.
    6. Select the IAM role created during the prerequisite steps.
    7. Create the Job.
  5. Run the initial executable again with the following command: sudo ./ota_demo_core_mqtt or sudo ./ota_demo_core_http.
  6. After the initial executable has finished running, go to the directory where the downloaded firmware image resides which is the path name used when creating an OTA job.
  7. Change the permissions of the downloaded firmware to make it executable, as it may be downloaded with read (user default) permissions only: chmod 775 ota_demo_core_mqtt2
  8. Run the downloaded firmware image with the following command: sudo ./ota_demo_core_mqtt2

Building and Running Demos

Before building the demos, ensure you have installed the prerequisite software. On Ubuntu 18.04 and 20.04, gcc, cmake, and OpenSSL can be installed with:

sudo apt install build-essential cmake libssl-dev

Build a single demo

  • Go to the root directory of the C-SDK.
  • Run cmake to generate the Makefiles: cmake -S . -Bbuild && cd build
  • Choose a demo from the list below or alternatively, run make help | grep demo:
defender_demo
http_demo_basic_tls
http_demo_mutual_auth
http_demo_plaintext
http_demo_s3_download
http_demo_s3_download_multithreaded
http_demo_s3_upload
jobs_demo_mosquitto
mqtt_demo_basic_tls
mqtt_demo_mutual_auth
mqtt_demo_plaintext
mqtt_demo_serializer
mqtt_demo_subscription_manager
ota_demo_core_http
ota_demo_core_mqtt
pkcs11_demo_management_and_rng
pkcs11_demo_mechanisms_and_digests
pkcs11_demo_objects
pkcs11_demo_sign_and_verify
shadow_demo_main
  • Replace demo_name with your desired demo then build it: make demo_name
  • Go to the build/bin directory and run any demo executables from there.

Build all configured demos

  • Go to the root directory of the C-SDK.
  • Run cmake to generate the Makefiles: cmake -S . -Bbuild && cd build
  • Run this command to build all configured demos: make
  • Go to the build/bin directory and run any demo executables from there.

Running corePKCS11 demos

The corePKCS11 demos do not require any AWS IoT resources setup, and are standalone. The demos build upon each other to introduce concepts in PKCS #11 sequentially. Below is the recommended order.

  1. pkcs11_demo_management_and_rng
  2. pkcs11_demo_mechanisms_and_digests
  3. pkcs11_demo_objects
  4. pkcs11_demo_sign_and_verify
    1. Please note that this demo requires the private and public key generated from pkcs11_demo_objects to be in the directory the demo is executed from.

Alternative option of Docker containers for running demos locally

Install Docker:

curl -fsSL https://get.docker.com -o get-docker.sh

sh get-docker.sh

Installing Mosquitto to run MQTT demos locally

The following instructions have been tested on an Ubuntu 18.04 environment with Docker and OpenSSL installed.

Download the official Docker image for Mosquitto 1.6.14. This version is deliberately chosen so that the Docker container can load certificates from the host system. Any version after 1.6.14 will drop privileges as soon as the configuration file has been read (before TLS certificates are loaded).

docker pull eclipse-mosquitto:1.6.14

If a Mosquitto broker with TLS communication needs to be run, ignore this step and proceed to the next step. A Mosquitto broker with plain text communication can be run by executing the command below.

docker run -it -p 1883:1883 --name mosquitto-plain-text eclipse-mosquitto:1.6.14

Set BROKER_ENDPOINT defined in demos/mqtt/mqtt_demo_plaintext/demo_config.h to localhost.

Ignore the remaining steps unless a Mosquitto broker with TLS communication also needs to be run.

For TLS communication with Mosquitto broker, server and CA credentials need to be created. Use OpenSSL commands to generate the credentials for the Mosquitto server.

# Generate CA key and certificate. Provide the Subject field information as appropriate for CA certificate.
openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout ca.key -out ca.crt
# Generate server key and certificate.# Provide the Subject field information as appropriate for Server certificate. Make sure the Common Name (CN) field is different from the root CA certificate.
openssl req -nodes -sha256 -new -keyout server.key -out server.csr # Sign with the CA cert.
openssl x509 -req -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365

Note: Make sure to use different Common Name (CN) detail between the CA and server certificates; otherwise, SSL handshake fails with exactly same Common Name (CN) detail in both the certificates.

port 8883

cafile /mosquitto/config/ca.crt
certfile /mosquitto/config/server.crt
keyfile /mosquitto/config/server.key

# Use this option for TLS mutual authentication (where client will provide CA signed certificate)
#require_certificate true
tls_version tlsv1.2
#use_identity_as_username true

Create a mosquitto.conf file to use port 8883 (for TLS communication) and providing path to the generated credentials.

Run the docker container from the local directory containing the generated credential and mosquitto.conf files.

docker run -it -p 8883:8883 -v $(pwd):/mosquitto/config/ --name mosquitto-basic-tls eclipse-mosquitto:1.6.14

Update demos/mqtt/mqtt_demo_basic_tls/demo_config.h to the following:
Set BROKER_ENDPOINT to localhost.
Set ROOT_CA_CERT_PATH to the absolute path of the CA certificate created in step 4. for the local Mosquitto server.

Installing httpbin to run HTTP demos locally

Run httpbin through port 80:

docker pull kennethreitz/httpbin
docker run -p 80:80 kennethreitz/httpbin

SERVER_HOST defined in demos/http/http_demo_plaintext/demo_config.h can now be set to localhost.

To run http_demo_basic_tls, download ngrok in order to create an HTTPS tunnel to the httpbin server currently hosted on port 80:

./ngrok http 80 # May have to use ./ngrok.exe depending on OS or filename of the executable

ngrok will provide an https link that can be substituted in demos/http/http_demo_basic_tls/demo_config.h and has a format of https://ABCDEFG12345.ngrok.io.

Set SERVER_HOST in demos/http/http_demo_basic_tls/demo_config.h to the https link provided by ngrok, without https:// preceding it.

You must also download the Root CA certificate provided by the ngrok https link and set ROOT_CA_CERT_PATH in demos/http/http_demo_basic_tls/demo_config.h to the file path of the downloaded certificate.

Installation

The C-SDK libraries and platform abstractions can be installed to a file system through CMake. To do so, run the following command in the root directory of the C-SDK. Note that installation is not required to run any of the demos.

cmake -S . -Bbuild -DBUILD_DEMOS=0 -DBUILD_TESTS=0
cd build
sudo make install

Note that because make install will automatically build the all target, it may be useful to disable building demos and tests with -DBUILD_DEMOS=0 -DBUILD_TESTS=0 unless they have already been configured. Super-user permissions may be needed if installing to a system include or system library path.

To install only a subset of all libraries, pass -DINSTALL_LIBS to install only the libraries you need. By default, all libraries will be installed, but you may exclude any library that you don't need from this list:

-DINSTALL_LIBS="DEFENDER;SHADOW;JOBS;OTA;OTA_HTTP;OTA_MQTT;BACKOFF_ALGORITHM;HTTP;JSON;MQTT;PKCS"

By default, the install path will be in the project directory of the SDK. You can also set -DINSTALL_TO_SYSTEM=1 to install to the system path for headers and libraries in your OS (e.g. /usr/local/include & /usr/local/lib for Linux).

Upon entering make install, the location of each library will be specified first followed by the location of all installed headers:

-- Installing: /usr/local/lib/libaws_iot_defender.so
-- Installing: /usr/local/lib/libaws_iot_shadow.so
...
-- Installing: /usr/local/include/aws/defender.h
-- Installing: /usr/local/include/aws/defender_config_defaults.h
-- Installing: /usr/local/include/aws/shadow.h
-- Installing: /usr/local/include/aws/shadow_config_defaults.h

You may also set an installation path of your choice by passing the following flags through CMake. Make sure to run the following command in the root directory of the C-SDK:

cmake -S . -Bbuild -DBUILD_DEMOS=0 -DBUILD_TESTS=0 \
-DCSDK_HEADER_INSTALL_PATH="/header/path" -DCSDK_LIB_INSTALL_PATH="/lib/path"
cd build
sudo make install

POSIX platform abstractions are used together with the C-SDK libraries in the demos. By default, these abstractions are also installed but can be excluded by passing the flag: -DINSTALL_PLATFORM_ABSTRACTIONS=0.

Lastly, a custom config path for any specific library can also be specified through the following CMake flags, allowing libraries to be compiled with a config of your choice:

-DDEFENDER_CUSTOM_CONFIG_DIR="defender-config-directory"
-DSHADOW_CUSTOM_CONFIG_DIR="shadow-config-directory"
-DJOBS_CUSTOM_CONFIG_DIR="jobs-config-directory"
-DOTA_CUSTOM_CONFIG_DIR="ota-config-directory"
-DHTTP_CUSTOM_CONFIG_DIR="http-config-directory"
-DJSON_CUSTOM_CONFIG_DIR="json-config-directory"
-DMQTT_CUSTOM_CONFIG_DIR="mqtt-config-directory"
-DPKCS_CUSTOM_CONFIG_DIR="pkcs-config-directory"

Note that the file name of the header should not be included in the directory.

Generating Documentation

Note: For pre-generated documentation, please visit Releases and Documentation section.

The Doxygen references were created using Doxygen version 1.9.2. To generate the Doxygen pages, use the provided Python script at tools/doxygen/generate_docs.py. Please ensure that each of the library submodules under libraries/standard/ and libraries/aws/ are cloned before using this script.

cd <CSDK_ROOT>
git submodule update --init --recursive --checkout
python3 tools/doxygen/generate_docs.py

The generated documentation landing page is located at docs/doxygen/output/html/index.html.


Author: aws
Source code: https://github.com/aws/aws-iot-device-sdk-embedded-C
License: MIT license

#aws 

Hong  Nhung

Hong Nhung

1659767568

11 Sai Lầm Xác Thực Hàng đầu Và Cách Khắc Phục Chúng

Bảo mật xác thực là một khía cạnh thiết yếu của phát triển ứng dụng web thường bị bỏ qua trong khi tạo sản phẩm. Tuy nhiên, nếu bạn có ý định nộp hồ sơ trực tuyến thì đó là ưu tiên hàng đầu. Trong bài viết này, tôi sẽ giải thích một số lỗi này và cách khắc phục chúng. Xin lưu ý rằng đây không phải là các vấn đề bảo mật chính mà OWASP khuyến nghị; thay vào đó, chúng là những vấn đề dễ sửa chữa mà tôi thường gặp.

Xác thực là gì?

Xác thực là quá trình xác nhận danh tính của người dùng hoặc quy trình. Khi xác thực bị vi phạm, những kẻ tấn công có thể giành quyền truy cập vào dữ liệu hoặc thông tin của người dùng, gây ra thiệt hại cho ứng dụng của bạn. Xác thực là một trong những cách mà kẻ tấn công có thể truy cập vào dữ liệu của người dùng và ứng dụng của bạn.

Khi nói đến xác thực, đây là mười một lỗi phổ biến cần tránh:

  1. Hiển thị thông báo lỗi cụ thể
  2. Tích hợp ID phiên vào một URL
  3. Xác thực biểu mẫu không chính xác
  4. Vệ sinh dạng thấp
  5. Chiến lược mật khẩu yếu
  6. Không thể sử dụng Xác thực hai yếu tố (2FA)
  7. Đặt lại mật khẩu không đúng
  8. Đăng xuất không an toàn
  9. Tấn công vũ phu
  10. Sử dụng câu hỏi bảo mật yếu
  11. Không bảo vệ được tuyến đường

Hiển thị thông báo lỗi cụ thể

Việc hiển thị một thông báo lỗi cụ thể là rất nguy hiểm vì nó có thể cho phép kẻ tấn công sử dụng phương pháp thử-và-sai tự động để xác định tên người dùng hoặc mật khẩu của người dùng.

Đây là một ví dụ sơ đồ về việc hiển thị một thông báo lỗi cụ thể. 

1

Khi xác thực một biểu mẫu trên ứng dụng web của bạn, bạn phải cẩn thận để không chỉ hiển thị một thông báo lỗi khi người dùng nhập một chi tiết không chính xác - chẳng hạn như “Mật khẩu của bạn không chính xác”. Nếu bạn hiển thị một thông báo lỗi cụ thể như vậy, kẻ tấn công sẽ nhận ra rằng địa chỉ email hoặc ID người dùng là có thật nhưng mật khẩu là sai. Điều này sẽ cho phép kẻ tấn công đề xuất mật khẩu cho người dùng đó.

Cách sửa lỗi này

  • Không bao giờ hiển thị thông báo lỗi cụ thể trên trang xác thực. Điều này cho phép kẻ tấn công biết thông tin nào bị thiếu và cho phép chúng sử dụng một cuộc tấn công bạo lực để đoán thông tin bị thiếu.
  • Hiển thị các thông báo lỗi như “chi tiết không chính xác”.

Tích hợp ID phiên vào một URL

ID phiên là một số mà máy chủ của trang web cung cấp cho một người dùng trong thời gian truy cập của người dùng đó. Cơ hội kẻ tấn công lấy được và lạm dụng mã thông báo phiên sẽ tăng lên nếu được đặt trực tiếp trong URL. Mặc dù rủi ro thấp hơn khi sử dụng HTTPS để kết nối với máy chủ web, nhưng vẫn có một mối nguy hiểm. Mặc dù URL HTTPS được mã hóa khi chuyển tiếp, chúng thường được lưu trong nhật ký máy chủ.

Dưới đây là một ví dụ sơ đồ về Tích hợp ID phiên vào URL.

2

Cách sửa lỗi này

  • Xác thực ID phiên ở phía máy chủ
  • Để tạo mã thông báo, hãy đảm bảo bạn sử dụng trình tạo ngẫu nhiên đủ an toàn.
  • Sử dụng bộ lọc để xóa ID phiên khỏi URL.

Xác thực biểu mẫu không chính xác.

Các cuộc tấn công chèn ép, rò rỉ bộ nhớ và hệ thống bị xâm nhập có thể xảy ra nếu dữ liệu được cung cấp trong đầu vào biểu mẫu không được kiểm tra hoặc định dạng đúng cách. Người dùng thường gửi mà không điền tất cả các thông tin cần thiết, vì vậy cần phải xác thực biểu mẫu của bạn để đảm bảo tất cả các thông tin yêu cầu đã được đáp ứng trước khi gửi đến máy chủ.

Cách sửa lỗi này

  • Đảm bảo rằng email có định dạng địa chỉ email.
  • Đảm bảo người dùng đã đáp ứng các tiêu chí cho biểu mẫu trước khi gửi
  • Xác thực biểu mẫu từ phụ trợ và giao diện người dùng bằng cách sử dụng thư viện hoặc khuôn khổ được cập nhật.

Một số thư viện được đề xuất mà tôi đề xuất để xác thực biểu mẫu là:

Tất cả các thư viện được liệt kê đều tốt cho việc xác thực biểu mẫu của bạn.

Vệ sinh dạng thấp 

Quá trình giữ cho đầu vào biểu mẫu của bạn sạch sẽ, được lọc và khử trùng khỏi tác nhân độc hại được gọi là quá trình khử trùng biểu mẫu. Vệ sinh đầu vào của bạn là điều bắt buộc vì nó ngăn ngừa các sai sót khi tiêm. Một biểu mẫu đầu vào được khử trùng tốt có thể ngăn chặn các cuộc tấn công sau:

Cross-site scripting (XSS): Đây là một loại lỗ hổng bảo mật thường được tìm thấy trong các ứng dụng web. Lỗ hổng này cho phép những kẻ tấn công chèn các tập lệnh phía máy khách vào các trang web mà người dùng xem. Cuộc tấn công này có thể gây ra nhiều tổn hại về bảo mật cho người dùng, chẳng hạn như chuyển hướng họ đến một trang web độc hại, buộc họ tải xuống ứng dụng phần mềm độc hại và đánh cắp dữ liệu của người dùng.

SQL injection: Những kẻ tấn công có thể can thiệp vào dữ liệu được gửi đến cơ sở dữ liệu của nó thông qua đầu vào biểu mẫu. 

Bằng cách khử trùng đầu vào biểu mẫu, bạn phải bảo vệ mã của mình và dữ liệu của người dùng khỏi tác nhân độc hại này và tất cả các lỗ hổng được liệt kê. Cá nhân tôi sử dụng DOM Purify , một thư viện làm sạch cho HTML và chuỗi, và nó có thể lọc bất kỳ thứ gì chứa HTML bẩn và ngăn chặn các cuộc tấn công XSS.

Cách sửa lỗi này

  • Sẽ dễ dàng và an toàn hơn đáng kể khi sử dụng danh sách cho phép cho các đầu vào được xác định rõ ràng như số, ngày tháng hoặc mã bưu điện. Về vấn đề đó, bạn có thể nêu rõ ràng những giá trị nào được phép và những giá trị nào không.
  • Sử dụng logic cho phép được xác định trước trong định nghĩa kiểu dữ liệu tích hợp với xác thực biểu mẫu HTML5.

Chiến lược mật khẩu yếu

Không có gì lạ khi bắt gặp một trang web không có gói mật khẩu mạnh theo thứ tự. Gần đây tôi đã thử một ứng dụng yêu cầu độ dài mật khẩu tối thiểu là năm ký tự. Khi các nhà phát triển cố gắng tìm ra sự cân bằng phù hợp giữa bảo mật và khả năng sử dụng, lỗ hổng này ngày càng phổ biến. Khi làm việc với mật khẩu, hãy đảm bảo mật khẩu bạn đề xuất cho người dùng hoặc mật khẩu mà người dùng tạo là hỗn hợp các ký hiệu, số và chữ cái viết hoa hỗn hợp. Tránh các kế hoạch mật khẩu yếu.

Cách sửa lỗi này

  • Yêu cầu người dùng nhập tối thiểu 12 hoặc 8 ký tự hoặc dài hơn.
  • Nên tránh sử dụng mật khẩu kết hợp tên người dùng hoặc tên công ty để bảo mật và khả năng sử dụng.
  • Chữ hoa và chữ thường nên được trộn lẫn.
  • Sử dụng thư viện để tính toán độ mạnh của mật khẩu, thận trọng khi chọn và kiểm tra các phụ thuộc và khả năng bảo trì tối thiểu.
  • Khi một người có hồ sơ công khai, hãy sử dụng tên hiển thị khác và tránh sử dụng địa chỉ email của người dùng làm tên hiển thị vì điều này mời spam.

Không thể sử dụng Xác thực hai yếu tố

Một sai lầm phổ biến khác mà tôi thấy với các cơ chế xác thực web là chúng không có bất kỳ biện pháp an toàn bổ sung nào. Xác thực hai yếu tố hiếm khi được các nhà phát triển sử dụng, đặc biệt là đối với các tài khoản hàng đầu. Xác thực hai yếu tố giúp bổ sung lớp bảo vệ thứ hai cho ứng dụng của bạn. Xác thực hai yếu tố rất quan trọng đối với bảo mật web vì nó ngay lập tức loại bỏ các nguy cơ về thông tin xác thực bị xâm phạm. Khi một mật khẩu bị bẻ khóa, bị đoán hoặc thậm chí bị nhiễm phần mềm độc hại, thì việc cấp quyền truy cập cho kẻ xâm nhập mà không có sự chấp thuận ở yếu tố xác thực thứ hai là không còn đủ.

Xác thực hai yếu tố là một lớp bảo mật bổ sung được thêm vào trang xác thực. Ví dụ về xác thực hai yếu tố này là SMS, email và OTP.

Đây là một ví dụ sơ đồ về xác thực hai yếu tố 

3

Cách triển khai xác thực hai yếu tố

Có nhiều cách khác nhau để sử dụng mã hóa 2FA. Mã thông báo RSA, trình tạo mã như Google Authenticator và Duo và gửi văn bản SMS mã một lần là tất cả các tùy chọn để triển khai công nghệ 2FA.

Đặt lại mật khẩu không đúng

Điều này không thường xuyên xảy ra, nhưng thỉnh thoảng, tôi thấy một ứng dụng web có khả năng này được triển khai không chính xác. Điều này thường là do mật khẩu của người dùng đã được gửi cho họ qua email hoặc mã thông báo được sử dụng để đặt lại mật khẩu không đủ mạnh. Việc gửi lại mật khẩu bản rõ cho người dùng cuối là một vấn đề khác ảnh hưởng đến việc đặt lại mật khẩu. Điều này thật tồi tệ vì nhiều lý do khác nhau, một trong số đó là mật khẩu được gửi qua email, được coi là không an toàn. Điều này có thể có nghĩa là mật khẩu được lưu trữ trong cơ sở dữ liệu mà không có đủ băm hoặc ở định dạng có thể bị đảo ngược, như base64.

Hashing  là một kỹ thuật được sử dụng để xác minh hoặc xác nhận chất lượng của nhiều loại đầu vào khác nhau. Trong các hệ thống xác thực, nó chủ yếu được sử dụng để ngăn chặn việc lưu trữ các mật khẩu văn bản rõ ràng, và Hashing khiến những kẻ tấn công vô cùng khó khăn trong việc giải mã các mật khẩu đã được lưu trữ.

Base64: Base64 là một phương pháp chuyển đổi dữ liệu nhị phân thành văn bản. Phương pháp này thường được sử dụng để gửi thông tin dựa trên nội dung qua Internet.

Cách sửa lỗi này

  • Luôn mã hóa mật khẩu người dùng trước khi lưu trữ, không lưu trữ ở dạng thô.
  • Chỉ gửi email giao dịch sau khi xác thực và xác minh địa chỉ email bằng cách kiểm tra các ký tự hợp lệ và gửi liên kết xác minh có mã thông báo.

Đăng xuất không an toàn

Đây là một lỗ hổng khác có thể gây ra sự tàn phá lớn cho một ứng dụng. Nó cũng cần thiết để cung cấp cho người dùng của bạn một cách an toàn để đăng xuất để các phiên của họ không thể bị chiếm đoạt. Nếu bạn đang lưu trữ số nhận dạng phiên ở phía máy chủ, phương pháp đăng xuất sẽ làm mất hiệu lực của nó và xóa cookie phiên trong trình duyệt. Điều này ngăn những kẻ tấn công có thể đánh cắp cookie phiên và sau đó sử dụng chúng để bắt đầu một phiên mới.

Cách sửa lỗi này

  • Khi người dùng đăng xuất, hãy xóa cookie phiên của trình duyệt và làm mất hiệu lực nhận dạng phiên nếu nó đang được lưu trữ trên máy chủ.
  • Trong quá trình đăng xuất, phiên người dùng và mã thông báo xác thực phải được vô hiệu hóa một cách chính xác.

Tấn công vũ phu

Brute force là một kỹ thuật hack được sử dụng để tìm ra thông tin đăng nhập của người dùng bằng cách thử nhiều thông tin đăng nhập có thể có. Trong cuộc tấn công này, tin tặc cố gắng đoán mật khẩu để vượt qua xác thực cho một tài khoản. Sử dụng các tập lệnh thử nhiều mật khẩu thường dùng từ từ điển và hàng triệu mật khẩu bị rò rỉ từ các lần vi phạm dữ liệu trước đó, những lần thử này có cơ hội thành công cao hơn.

Cách sửa lỗi này

  • Hạn chế các nỗ lực đăng nhập vào một địa chỉ hoặc dải IP xác định bằng cách chặn quyền truy cập vào URL xác thực.
  • Không sử dụng thuật ngữ nào từ từ điển bằng bất kỳ ngôn ngữ nào. Thay vì sử dụng các từ, tốt hơn là sử dụng các chuỗi ký tự ngẫu nhiên.
  • Chặn các địa chỉ IP độc hại bằng CAPTCHAS.
  • Theo dõi các lần đăng nhập thất bại của người dùng và khóa tài khoản.

Sử dụng câu hỏi bảo mật không đầy đủ

Một câu hỏi bảo mật hoặc từ dễ nhớ cũng có thể hỗ trợ trong việc bảo vệ chống lại các cuộc tấn công tự động. Tôi đã gặp phải các câu hỏi bảo mật yếu có câu trả lời có thể đoán trước, cho phép kẻ tấn công đề xuất hoặc đoán câu trả lời và có được quyền truy cập vào dữ liệu của người dùng.

Dưới đây là một số câu hỏi bảo mật phổ biến mà tôi đã gặp:

  • Bạn sinh ra ở thành phố nào?
  • Ngày sinh của bạn là gì?
  • bạn đã học trường trung học phổ thông nào?
  • Tên thời con gái của mẹ bạn là gì?

Tránh tất cả những câu hỏi này vì tin tặc có thể đoán chúng do một số thông tin trên Google hoặc các hồ sơ trực tuyến khác của chúng tôi.

Cách sửa lỗi này

  • Đề xuất những câu hỏi người dùng dễ nhớ nhưng kẻ tấn công khó đề xuất
  • Lưu trữ câu trả lời bằng thuật toán băm an toàn như Bcrypt. Bcrypt là một thuật toán được sử dụng để băm và xác minh mật khẩu. Nó giúp giảm nguy cơ tội phạm mạng tấn công ứng dụng của bạn thông qua mật khẩu.

Không bảo vệ các tuyến đường

Một lỗi khác mà tôi đã thấy các nhà phát triển mắc phải khi nói đến xác thực là "không bảo vệ được tuyến đường." Điều quan trọng là phải bảo mật các tuyến đường cụ thể trong ứng dụng của bạn khỏi những người dùng không được xác thực, vì điều này sẽ ngăn những người dùng không xác định truy cập vào một số dữ liệu riêng tư của ứng dụng của bạn.

Cách sửa lỗi này

  • Bảo vệ tuyến đường bạn muốn người dùng chưa xác thực truy cập.
  • Nếu người dùng đang cố gắng truy cập vào một tuyến đường cụ thể, hãy chuyển hướng họ đến trang đăng nhập / đăng ký nếu chúng chưa được xác thực

Sự kết luận

Khi triển khai xác thực trên trang web của mình, bạn phải hết sức thận trọng với tư cách là nhà phát triển vì một số phương pháp có thể gây hại cho chương trình của bạn và mở ra cánh cửa cho những kẻ tấn công chiếm quyền kiểm soát dữ liệu của người dùng và ứng dụng. Hy vọng rằng, bài viết này đã chỉ ra những lỗi như vậy và đưa ra lời khuyên về cách khắc phục chúng.

Liên kết: https://blog.openreplay.com/11-authentication-mistakes-and-how-to-fix-them

#authentication

Josefa  Corwin

Josefa Corwin

1659852060

A Template Language That Completely Separates Structure and Logic/Ruby

Curly

Curly is a template language that completely separates structure and logic. Instead of interspersing your HTML with snippets of Ruby, all logic is moved to a presenter class.

Installing

Installing Curly is as simple as running gem install curly-templates. If you're using Bundler to manage your dependencies, add this to your Gemfile

gem 'curly-templates'

Curly can also install an application layout file, replacing the .erb file commonly created by Rails. If you wish to use this, run the curly:install generator.

$ rails generate curly:install

How to use Curly

In order to use Curly for a view or partial, use the suffix .curly instead of .erb, e.g. app/views/posts/_comment.html.curly. Curly will look for a corresponding presenter class named Posts::CommentPresenter. By convention, these are placed in app/presenters/, so in this case the presenter would reside in app/presenters/posts/comment_presenter.rb. Note that presenters for partials are not prepended with an underscore.

Add some HTML to the partial template along with some Curly components:

<!-- app/views/posts/_comment.html.curly -->
<div class="comment">
  <p>
    {{author_link}} posted {{time_ago}} ago.
  </p>

  {{body}}

  {{#author?}}
    <p>{{deletion_link}}</p>
  {{/author?}}
</div>

The presenter will be responsible for providing the data for the components. Add the necessary Ruby code to the presenter:

# app/presenters/posts/comment_presenter.rb
class Posts::CommentPresenter < Curly::Presenter
  presents :comment

  def body
    SafeMarkdown.render(@comment.body)
  end

  def author_link
    link_to @comment.author.name, @comment.author, rel: "author"
  end

  def deletion_link
    link_to "Delete", @comment, method: :delete
  end

  def time_ago
    time_ago_in_words(@comment.created_at)
  end

  def author?
    @comment.author == current_user
  end
end

The partial can now be rendered like any other, e.g. by calling

render 'comment', comment: comment
render comment
render collection: post.comments

Curly components are surrounded by curly brackets, e.g. {{hello}}. They always map to a public method on the presenter class, in this case #hello. Methods ending in a question mark can be used for conditional blocks, e.g. {{#admin?}} ... {{/admin?}}.

Identifiers

Curly components can specify an identifier using the so-called dot notation: {{x.y.z}}. This can be very useful if the data you're accessing is hierarchical in nature. One common example is I18n:

<h1>{{i18n.homepage.header}}</h1>
# In the presenter, the identifier is passed as an argument to the method. The
# argument will always be a String.
def i18n(key)
  translate(key)
end

The identifier is separated from the component name with a dot. If the presenter method has a default value for the argument, the identifier is optional – otherwise it's mandatory.

Attributes

In addition to an identifier, Curly components can be annotated with attributes. These are key-value pairs that affect how a component is rendered.

The syntax is reminiscent of HTML:

<div>{{sidebar rows=3 width=200px title="I'm the sidebar!"}}</div>

The presenter method that implements the component must have a matching keyword argument:

def sidebar(rows: "1", width: "100px", title:); end

All argument values will be strings. A compilation error will be raised if

  • an attribute is used in a component without a matching keyword argument being present in the method definition; or
  • a required keyword argument in the method definition is not set as an attribute in the component.

You can define default values using Ruby's own syntax. Additionally, if the presenter method accepts arbitrary keyword arguments using the **doublesplat syntax then all attributes will be valid for the component, e.g.

def greetings(**names)
  names.map {|name, greeting| "#{name}: #{greeting}!" }.join("\n")
end
{{greetings alice=hello bob=hi}}
<!-- The above would be rendered as: -->
alice: hello!
bob: hi!

Note that since keyword arguments in Ruby are represented as Symbol objects, which are not garbage collected in Ruby versions less than 2.2, accepting arbitrary attributes represents a security vulnerability if your application allows untrusted Curly templates to be rendered. Only use this feature with trusted templates if you're not on Ruby 2.2 yet.

Conditional blocks

If there is some content you only want rendered under specific circumstances, you can use conditional blocks. The {{#admin?}}...{{/admin?}} syntax will only render the content of the block if the admin? method on the presenter returns true, while the {{^admin?}}...{{/admin?}} syntax will only render the content if it returns false.

Both forms can have an identifier: {{#locale.en?}}...{{/locale.en?}} will only render the block if the locale? method on the presenter returns true given the argument "en". Here's how to implement that method in the presenter:

class SomePresenter < Curly::Presenter
  # Allows rendering content only if the locale matches a specified identifier.
  def locale?(identifier)
    current_locale == identifier
  end
end

Furthermore, attributes can be set on the block. These only need to be specified when opening the block, not when closing it:

{{#square? width=3 height=3}}
  <p>It's square!</p>
{{/square?}}

Attributes work the same way as they do for normal components.

Collection blocks

Sometimes you want to render one or more items within the current template, and splitting out a separate template and rendering that in the presenter is too much overhead. You can instead define the template that should be used to render the items inline in the current template using the collection block syntax.

Collection blocks are opened using an asterisk:

{{*comments}}
  <li>{{body}} ({{author_name}})</li>
{{/comments}}

The presenter will need to expose the method #comments, which should return a collection of objects:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def comments
    @post.comments
  end
end

The template within the collection block will be used to render each item, and it will be backed by a presenter named after the component – in this case, comments. The name will be singularized and Curly will try to find the presenter class in the following order:

  • Posts::ShowPresenter::CommentPresenter
  • Posts::CommentPresenter
  • CommentPresenter

This allows you some flexibility with regards to how you want to organize these nested templates and presenters.

Note that the nested template will only have access to the methods on the nested presenter, but all variables passed to the "parent" presenter will be forwarded to the nested presenter. In addition, the current item in the collection will be passed, as well as that item's index in the collection:

class Posts::CommentPresenter < Curly::Presenter
  presents :post, :comment, :comment_counter

  def number
    # `comment_counter` is automatically set to the item's index in the collection,
    # starting with 1.
    @comment_counter
  end

  def body
    @comment.body
  end

  def author_name
    @comment.author.name
  end
end

Collection blocks are an alternative to splitting out a separate template and rendering that from the presenter – which solution is best depends on your use case.

Context blocks

While collection blocks allow you to define the template that should be used to render items in a collection right within the parent template, context blocks allow you to define the template for an arbitrary context. This is very powerful, and can be used to define widget-style components and helpers, and provide an easy way to work with structured data. Let's say you have a comment form on your page, and you'd rather keep the template inline. A simple template could look like:

<!-- post.html.curly -->
<h1>{{title}}</h1>
{{body}}

{{@comment_form}}
  <b>Name: </b> {{name_field}}<br>
  <b>E-mail: </b> {{email_field}}<br>
  {{comment_field}}

  {{submit_button}}
{{/comment_form}}

Note that an @ character is used to denote a context block. Like with collection blocks, a separate presenter class is used within the block, and a simple convention is used to find it. The name of the context component (in this case, comment_form) will be camel cased, and the current presenter's namespace will be searched:

class PostPresenter < Curly::Presenter
  presents :post
  def title; @post.title; end
  def body; markdown(@post.body); end

  # A context block method *must* take a block argument. The return value
  # of the method will be used when rendering. Calling the block argument will
  # render the nested template. If you pass a value when calling the block
  # argument it will be passed to the presenter.
  def comment_form(&block)
    form_for(Comment.new, &block)
  end

  # The presenter name is automatically deduced.
  class CommentFormPresenter < Curly::Presenter
    # The value passed to the block argument will be passed in a parameter named
    # after the component.
    presents :comment_form

    # Any parameters passed to the parent presenter will be forwarded to this
    # presenter as well.
    presents :post

    def name_field
      @comment_form.text_field :name
    end

    # ...
  end
end

Context blocks were designed to work well with Rails' helper methods such as form_for and content_tag, but you can also work directly with the block. For instance, if you want to directly control the value that is passed to the nested presenter, you can call the call method on the block yourself:

def author(&block)
  content_tag :div, class: "author" do
    # The return value of `call` will be the result of rendering the nested template
    # with the argument. You can post-process the string if you want.
    block.call(@post.author)
  end
end

Context shorthand syntax

If you find yourself opening a context block just in order to use a single component, e.g. {{@author}}{{name}}{{/author}}, you can use the shorthand syntax instead: {{author:name}}. This works for all component types, e.g.

{{#author:admin?}}
  <p>The author is an admin!</p>
{{/author:admin?}}

The syntax works for nested contexts as well, e.g. {{comment:author:name}}. Any identifier and attributes are passed to the target component, which in this example would be {{name}}.

Setting up state

Although most code in Curly presenters should be free of side effects, sometimes side effects are required. One common example is defining content for a content_for block.

If a Curly presenter class defines a setup! method, it will be called before the view is rendered:

class PostPresenter < Curly::Presenter
  presents :post

  def setup!
    content_for :title, post.title

    content_for :sidebar do
      render 'post_sidebar', post: post
    end
  end
end

Escaping Curly syntax

In order to have {{ appear verbatim in the rendered HTML, use the triple Curly escape syntax:

This is {{{escaped}}.

You don't need to escape the closing }}.

Comments

If you want to add comments to your Curly templates that are not visible in the rendered HTML, use the following syntax:

{{! This is some interesting stuff }}

Presenters

Presenters are classes that inherit from Curly::Presenter – they're usually placed in app/presenters/, but you can put them anywhere you'd like. The name of the presenter classes match the virtual path of the view they're part of, so if your controller is rendering posts/show, the Posts::ShowPresenter class will be used. Note that Curly is only used to render a view if a template can be found – in this case, at app/views/posts/show.html.curly.

Presenters can declare a list of accepted variables using the presents method:

class Posts::ShowPresenter < Curly::Presenter
  presents :post
end

A variable can have a default value:

class Posts::ShowPresenter < Curly::Presenter
  presents :post
  presents :comment, default: nil
end

Any public method defined on the presenter is made available to the template as a component:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def title
    @post.title
  end

  def author_link
    # You can call any Rails helper from within a presenter instance:
    link_to author.name, profile_path(author), rel: "author"
  end

  private

  # Private methods are not available to the template, so they're safe to
  # use.
  def author
    @post.author
  end
end

Presenter methods can even take an argument. Say your Curly template has the content {{t.welcome_message}}, where welcome_message is an I18n key. The following presenter method would make the lookup work:

def t(key)
  translate(key)
end

That way, simple ``functions'' can be added to the Curly language. Make sure these do not have any side effects, though, as an important part of Curly is the idempotence of the templates.

Layouts and content blocks

Both layouts and content blocks (see content_for) use yield to signal that content can be inserted. Curly works just like ERB, so calling yield with no arguments will make the view usable as a layout, while passing a Symbol will make it try to read a content block with the given name:

# Given you have the following Curly template in
# app/views/layouts/application.html.curly
#
#   <html>
#     <head>
#       <title>{{title}}</title>
#     </head>
#     <body>
#       <div id="sidebar">{{sidebar}}</div>
#       {{body}}
#     </body>
#   </html>
#
class ApplicationLayout < Curly::Presenter
  def title
    "You can use methods just like in any other presenter!"
  end

  def sidebar
    # A view can call `content_for(:sidebar) { "some HTML here" }`
    yield :sidebar
  end

  def body
    # The view will be rendered and inserted here:
    yield
  end
end

Rails helper methods

In order to make a Rails helper method available as a component in your template, use the exposes_helper method:

class Layouts::ApplicationPresenter < Curly::Presenter
  # The components {{sign_in_path}} and {{root_path}} are made available.
  exposes_helper :sign_in_path, :root_path
end

Testing

Presenters can be tested directly, but sometimes it makes sense to integrate with Rails on some levels. Currently, only RSpec is directly supported, but you can easily instantiate a presenter:

SomePresenter.new(context, assigns)

context is a view context, i.e. an object that responds to render, has all the helper methods you expect, etc. You can pass in a test double and see what you need to stub out. assigns is the hash containing the controller and local assigns. You need to pass in a key for each argument the presenter expects.

Testing with RSpec

In order to test presenters with RSpec, make sure you have rspec-rails in your Gemfile. Given the following presenter:

# app/presenters/posts/show_presenter.rb
class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def body
    Markdown.render(@post.body)
  end
end

You can test the presenter methods like this:

# You can put this in your `spec_helper.rb`.
require 'curly/rspec'

# spec/presenters/posts/show_presenter_spec.rb
describe Posts::ShowPresenter, type: :presenter do
  describe "#body" do
    it "renders the post's body as Markdown" do
      assign(:post, double(:post, body: "**hello!**"))
      expect(presenter.body).to eq "<strong>hello!</strong>"
    end
  end
end

Note that your spec must be tagged with type: :presenter.

Examples

Here is a simple Curly template – it will be looked up by Rails automatically.

<!-- app/views/posts/show.html.curly -->
<h1>{{title}}<h1>
<p class="author">{{author}}</p>
<p>{{description}}</p>

{{comment_form}}

<div class="comments">
  {{comments}}
</div>

When rendering the template, a presenter is automatically instantiated with the variables assigned in the controller or the render call. The presenter declares the variables it expects with presents, which takes a list of variables names.

# app/presenters/posts/show_presenter.rb
class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def title
    @post.title
  end

  def author
    link_to(@post.author.name, @post.author, rel: "author")
  end

  def description
    Markdown.new(@post.description).to_html.html_safe
  end

  def comments
    render 'comment', collection: @post.comments
  end

  def comment_form
    if @post.comments_allowed?
      render 'comment_form', post: @post
    else
      content_tag(:p, "Comments are disabled for this post")
    end
  end
end

Caching

Caching is handled at two levels in Curly – statically and dynamically. Static caching concerns changes to your code and templates introduced by deploys. If you do not wish to clear your entire cache every time you deploy, you need a way to indicate that some view, helper, or other piece of logic has changed.

Dynamic caching concerns changes that happen on the fly, usually made by your users in the running system. You wish to cache a view or a partial and have it expire whenever some data is updated – usually whenever a specific record is changed.

Dynamic Caching

Because of the way logic is contained in presenters, caching entire views or partials by the data they present becomes exceedingly straightforward. Simply define a #cache_key method that returns a non-nil object, and the return value will be used to cache the template.

Whereas in ERB you would include the cache call in the template itself:

<% cache([@post, signed_in?]) do %>
  ...
<% end %>

In Curly you would instead declare it in the presenter:

class Posts::ShowPresenter < Curly::Presenter
  presents :post

  def cache_key
    [@post, signed_in?]
  end
end

Likewise, you can add a #cache_duration method if you wish to automatically expire the fragment cache:

class Posts::ShowPresenter < Curly::Presenter
  ...

  def cache_duration
    30.minutes
  end
end

In order to set any cache option, define a #cache_options method that returns a Hash of options:

class Posts::ShowPresenter < Curly::Presenter
  ...

  def cache_options
    { compress: true, namespace: "my-app" }
  end
end

Static Caching

Static caching will only be enabled for presenters that define a non-nil #cache_key method (see Dynamic Caching.)

In order to make a deploy expire the cache for a specific view, set the version of the view to something new, usually by incrementing by one:

class Posts::ShowPresenter < Curly::Presenter
  version 3

  def cache_key
    # Some objects
  end
end

This will change the cache keys for all instances of that view, effectively expiring the old cache entries.

This works well for views, or for partials that are rendered in views that themselves are not cached. If the partial is nested within a view that is cached, however, the outer cache will not be expired. The solution is to register that the inner partial is a dependency of the outer one such that Curly can automatically deduce that the outer partial cache should be expired:

class Posts::ShowPresenter < Curly::Presenter
  version 3
  depends_on 'posts/comment'

  def cache_key
    # Some objects
  end
end

class Posts::CommentPresenter < Curly::Presenter
  version 4

  def cache_key
    # Some objects
  end
end

Now, if the version of Posts::CommentPresenter is bumped, the cache keys for both presenters would change. You can register any number of view paths with depends_on.

Curly integrates well with the caching mechanism in Rails 4 (or Cache Digests in Rails 3), so the dependencies defined with depends_on will be tracked by Rails. This will allow you to deploy changes to your templates and have the relevant caches automatically expire.

Thanks

Thanks to Zendesk for sponsoring the work on Curly.

Contributors

Build Status


Author: zendesk
Source code: https://github.com/zendesk/curly

#ruby   #ruby-on-rails 

davis mike

1626331037

Caching In WordPress: What You Need to Learn?

WordPress caching has nothing new to showcase in this context. WordPress websites also run on a specific server system and you have to make sure these servers work well for user engagement. So caching can help your website server work effectively to serve too many visitors collectively. The commonly requested items can be converted into varied copies that the website server doesn’t want to showcase every time to every website visitor. Classification of Caching is usually divided into two kinds. The Client-Side Caching & the Server Side Caching. Where client-side caching has nothing to do with your website, Server Side Caching is usually its opposite. Read more on https://bit.ly/3rbqvVh

#caching plugins #server side caching #client side caching #wordpress websites #wordpress caching

2016-2017 inside Evaluation: How must the Los Angeles Kings hire Dusti

For the up coming thirty day period or 2, wel be having a seem to be at the gamers who produced the Los Angeles Kings2016-17 year what it was: a crushing frustration that acquired All those fired an up-and-down trip which maintained in direction of be both of those uncommon and acquainted. Fairly than the positive-undesirable-long run-quality layout wee made use of inside of last seasons, wel talk to a critical speculate and solution it utilizing it what we observed this calendar year.(Seriously, inside this scenario, wel check with 2 significant issues...)Why need to the Kings section with their #1 decide on inside of purchase in direction of unload Dustin Brown agreement? “WHY WOULD Oneself EVEN Talk to THAT QUESTION”I can say with self esteem that this is a person of the minimum amount beloved components I include at any time prepared, match or non-video game identical. Believe that me Whilst I say that I delight in Dustin Brown, and that my enjoy for him goes over and above his design and style of participate in, his management of the Kings, and his propensity toward do foolish components upon the bench. He is, very easily area, the design and style of individual your self assume your kid grows up towards be https://www.storekingsapparel.com/Alex_Turcotte_Jersey-166, and his personality and commitment towards loved ones are unimpeachable. Moreover, Sean Avery is and will normally be a P.O.S. Nevertheless, Brown is too a before long in the direction of be 30-3 12 months outdated still left-winger with declining output and a significant, albatross-which include agreement. Provided that the Kings are saddled with a different unattractive agreement apart from Brown be concerned, Kings lovers, be amazingly anxious and a determined require for quickness and ability in just their final-6, it is very last year towards lean sentimental with roster alternate options. Therefore, Il create 2 arguments below. The very first is why the Kings need to deliver a bundle with the Vegas Golden Knights in direction of comprise them acquire Dustin Brown Austin Wagner Jersey, even at the price tag of their 1st-spherical pick out (#11) in just the 2017 NHL Draft. The moment argument, which is a much even more possibly predicament, is how the Kings need to seek the services of Brown in just 2017-2018 if he stays upon the roster.I will be trustworthy, I am not persuaded of the argument that follows, and recognize that it fails toward acquire into account Brown management upon and off the ice Alex Turcotte Jersey. I am, Regrettably, cautious of the “what shed towards this personnel is grit!line of questioning, as a result incorporate favored towards discard it for the period staying. I way too comprehend that plenty of will uncover the principle of working the #11 select a awful one particular for a staff with very little organizational element. That is totally a sensible simple fact, nevertheless for a workers with, inside of my estimation, a 2-12 months Cup window, the chance in the direction of increase ability toward the roster getting Brown freed-up AAV is as well essential in direction of move up. Within addition, I do not worthy of to start with spherical selections Very as significant as some others, at bare minimum not presented this team recent context...hence there that.How poor is Dustin Brown agreement? With 5 many years currently being and a $5 Brett Sutter Jersey.875 million ordinary yearly cost, Brown offer is broadly regarded as 1 of the worst in just the league. Inspite of his better 2016-2017 year, the trajectory of Brown upon-ice output is apparent and hopes of a late-point revival possibly unrealistic, even with a looser offensive philosophy needed inside 2017-2018. As Jon Rosen pointed toward inside of his individual investigation of Brown 2016-2017 time, Brown improved generation masked few stressing traits, and there is space for issue that he dragged down his 2 utmost regular centermen, Anze Kopitar and Nic Dowd. Consequently what my issue? My position is that we learnt ultimate time that Brown and Gaborik are no extended final-6 forwards and hiding them inside the backside-6 is a recipe for catastrophe (not towards point out a clogged developmental pipeline). Alternatively, the Kings ought to rethink their very clear unwillingness toward package their #11 select and perspective if the Vegas Golden Knights would assert it and Brown management. Brown agreement is a person yr for a longer time and a single million heavier than Gaborik, and if the intent is toward unload 1 of them, then Brown is the 1 toward shed, and it would produce obtaining out Gaborik that substantially simpler towards swallow.What would I endorse performing with the $5.875 million of further more region down below the cap right after these types of a go? I consider there are couple of intelligent circumstances accessible. All right, yet truly, how really should the Kings seek the services of Dustin Brown within just 2017-2018? “This hurts, and your moment ponder alterations practically nothing.”Now that I contain used 3 hundred and seventy 6 text upon one thing that is not relocating toward come about and will crank out random persons enraged with me, let chat around how the Kings ought to seek the services of Dustin Brown upcoming period. Towards begin, I do not imagine John Stevens must progress tying Brown toward Kopitar. Brown observed 34% of his amount of money ice season with Anze, and either my eye and the quantities direct me toward think he is a drag upon our selection one particular heart. If Stevens is hunting towards boost offensive generation towards Kopitar, selling him with greater ability upon his wings is a precedence. I furthermore do not feel that tying Brown in the direction of a 3rd-line purpose, heading with Nic Dowd (should really Vegas not decide on him upon Wednesday), is a smart thought. Collectively for 29% of Brown general ice season inside 2016-2017, the 2 preserved in the direction of deliver a Objectives For/60 (5v5) of 1.94 whilst conceding 2.81 Plans Versus/60 (5v5). Dowd includes detailed ability and house for enhancement, and it would feel that he and Brown would ease in opposition to some breakup following calendar year. My prescription for Brown is 2017-2018 is a instant-line function with Jeff Carter. Inside 188 minutes of 5v5 period collectively remaining period, they created an modern 3.51 objectives for/60 though conceding an both modern 1.59 plans in opposition to/60. The two start out generally inside of the offensive zone, both equally effort and hard work nicely biking the puck, and Brown greater willingness in direction of take his video game back again toward a world wide web-entrance existence orientation will help Carter natural and organic tendency toward shoot puck https://www.storekingsapparel.com/Denis_Dejordy_Jersey-60.ConclusionDustin Brown is a remarkable specific, a Kings legend, and neither of individuals will at any time difference. It is not his fault that he signed a significant, properly-deserved, deal at the identical issue that his video game deserted him, and there is no wonder that he desires a return toward glory much more than any of us. Continue to, the Kings are within a precarious nation and their chances toward gain a further Stanley Cup are shrinking calendar year by means of 12 months. If the workers thinks that his participate in will progress in direction of deteriorate and that his agreement will keep away from them in opposition to creating for the potential, it would be clever in direction of take into account the worthy of of their 2017 #11 draft decide on. If it doesn hard work (and possibly it now hasn labored), let be expecting they come across the specifically job for him.