ADD: Http Support by surajmaurya-git · Pull Request #4 · anedyaio/anedya-dev-core

surajmaurya-git · 2026-05-22T13:18:58Z

No description provided.

…re API endpoint paths

gemini-code-assist

Code Review

This pull request adds HTTP support to the Anedya SDK, allowing operations like device binding and data submission via REST API. It also refactors configuration to use Kconfig and applies consistent formatting. The review highlights critical issues including missing struct members for dynamic allocation, potential null pointer dereferences in OTA and transaction handling, and a buffer overflow risk in response parsing. Additionally, the feedback recommends avoiding large stack allocations and cleaning up redundant code declarations.

gemini-code-assist · 2026-05-22T13:22:11Z

+  char http_base_url[100]; // e.g. "device.ap-in-1.anedya.io"
+#endif
+  uint8_t is_connected;
+  anedya_txn_store_t txn_store;


The anedya_client_t structure is missing the tx_buffer and rx_buffer members, which are required when ANEDYA_ENABLE_DYNAMIC_ALLOCATION is defined, as seen in the initialization code in src/anedya_client.c (lines 22 and 25). This will result in a compilation error.

gemini-code-assist · 2026-05-22T13:22:11Z

+  int str_len = payload_len;
+  memset(str, 0, ANEDYA_RX_BUFFER_SIZE);
+  memset(buffer, 0, ANEDYA_RX_BUFFER_SIZE);
+  memcpy(str, payload, payload_len);
+  memcpy(buffer, str, str_len);
+  // printf("Payload Received: %s\r\n", str);
+  str[str_len] = '\0';
+  buffer[str_len] = '\0';


Critical buffer overflow and out-of-bounds write risk. The payload_len is not validated against ANEDYA_RX_BUFFER_SIZE before the memcpy operations. If payload_len is too large, it will overflow the str and buffer arrays. Additionally, writing a null terminator at str[str_len] and buffer[str_len] is out of bounds if str_len equals ANEDYA_RX_BUFFER_SIZE.

Suggested change

int str_len = payload_len;

memset(str, 0, ANEDYA_RX_BUFFER_SIZE);

memset(buffer, 0, ANEDYA_RX_BUFFER_SIZE);

memcpy(str, payload, payload_len);

memcpy(buffer, str, str_len);

// printf("Payload Received: %s\r\n", str);

str[str_len] = '\0';

buffer[str_len] = '\0';

if (payload_len >= ANEDYA_RX_BUFFER_SIZE) {

_anedya_interface_std_out("Error: Payload too large for RX buffer");

return;

}

int str_len = payload_len;

memset(str, 0, ANEDYA_RX_BUFFER_SIZE);

memset(buffer, 0, ANEDYA_RX_BUFFER_SIZE);

memcpy(str, payload, payload_len);

memcpy(buffer, str, str_len);

str[str_len] = '\0';

buffer[str_len] = '\0';

gemini-code-assist · 2026-05-22T13:22:12Z

+    if (_anedya_uuid_parse(deployment_id, dst->deployment_id) != ANEDYA_OK)
+      return ANEDYA_ERR_PARSE_ERROR;
+
+    // assetId


Potential null pointer dereference. The asset member of anedya_op_ongoing_asset_list_t is a pointer that is accessed here without ensuring it points to a valid anedya_asset_t structure. If the caller has not pre-allocated these structures, the application will crash.

gemini-code-assist · 2026-05-22T13:22:12Z

+  if (!txn_id || JSON_TEXT != json_getType(txn_id)) {
+    _anedya_interface_std_out(
+        "Error, the reqId property is not found in the response.");
+  }


The function continues execution even if the reqId property is missing or invalid. This will lead to a null pointer dereference when json_getValue(txn_id) is called on line 360. A return statement should be added after logging the error.

Suggested change

if (!txn_id || JSON_TEXT != json_getType(txn_id)) {

_anedya_interface_std_out(

"Error, the reqId property is not found in the response.");

}

if (!txn_id || JSON_TEXT != json_getType(txn_id)) {

_anedya_interface_std_out(

"Error, the reqId property is not found in the response.");

return;

}

cannot add api missing it

gemini-code-assist · 2026-05-22T13:22:12Z

+#endif /* ANEDYA_CONNECTION_METHOD_MQTT */
+
+#ifdef ANEDYA_CONNECTION_METHOD_HTTP
+  char resp_buf[ANEDYA_RX_BUFFER_SIZE];


Allocating a large buffer like resp_buf[ANEDYA_RX_BUFFER_SIZE] on the stack is dangerous in embedded systems and can lead to stack overflow. It is better to use a buffer from the client instance or allocate it dynamically.

will it it later when optimize for the dynamzic allocation

gemini-code-assist · 2026-05-22T13:22:12Z

+#ifdef ANEDYA_CONNECTION_METHOD_HTTP
+void _anedya_handle_http_txn_response(anedya_client_t *cl, char *payload, int payload_len, anedya_txn_t *txn);
+#endif


The declaration of _anedya_handle_http_txn_response is duplicated here. It is already declared on lines 81-83.

gemini-code-assist · 2026-05-22T13:22:12Z

+  anedya_err_t err = _anedya_txn_register(client, txn);
+  if (err != ANEDYA_OK) {
+    return err;
+  }
+


Redundant nested #ifdef blocks for ANEDYA_CONNECTION_METHOD_MQTT found here.

#ifdef ANEDYA_CONNECTION_METHOD_MQTT p = anedya_json_nstr(p, "reqId", slot_number, digitLen, &marker); #endif

…t payload size validation in response handler

anedyasystems · 2026-05-22T16:08:41Z

+ *
+ * In HTTP mode there is no long-lived connection to establish. This function
+ * simply validates the configuration, builds the base URL, and marks
+ * is_connected = 1 so that all operation functions can proceed.


is_connected = 1 is misleading when there is no connection. Client programs can break when there is no internet but called client_connect by changing connection method to HTTP by mistake. As programs can simply call is_connected and see it is set to 1 while ther might be situation that device isn't even connected. In fact I suggest that we remove anedya_client_connect from HTTP altogether when HTTP mode is selcted, as there's literally nothing to connect.

Or other option is throw ANEDYA_UNSUPPORTED_FUNCTION error. The only purpose is if we don't do this users will never know the failure until it happens, as same code which was written for MQTT for checking connection status will keep workign with HTTP mode until operations do not work. That will be a silent failure.

anedyasystems · 2026-05-22T16:11:24Z

+ *
+ * @param[in] client Pointer to the anedya_client_t to operate on.
+ * @retval ANEDYA_OK always.
+ */


Same applies for disconnect, I suggest remove these methods from HTTP mode. This will force users to handle things as per MQTT or HTTP.

anedyasystems · 2026-05-22T16:30:34Z

+#endif /* ANEDYA_CONNECTION_METHOD_MQTT */
+
+#ifdef ANEDYA_CONNECTION_METHOD_HTTP
+void _anedya_handle_http_txn_response(anedya_client_t *cl, char *payload,


If possible let's keep the txn_response handling function common between both MQTT and HTTP mode and rather just adjust the core difference that is changed inside that function as per HTTP or MQTT mode. It'll create future bugs when we add more operations into it as we need to maintain now both HTTP part and MQTT part. Keep the path same as long as possible.

surajmaurya-git and others added 9 commits November 17, 2025 15:27

added ongoing ota status feature

90c8ee8

updated ongoing ota function: added req parameter

e719263

handle null data

a592529

correct pem cert & improvement

f622935

Merge commit 'f6229358f5225ff690da5939a4196d4d307ef9f3' into HEAD

6481ee3

fix: add ongoing OTA response handler and include JSON parsing headers

64ba3c2

feat: http support

097899d

fix: correct formatting in device ID parsing loop

1af4342

refactor: enable reqId for all connection methods and update valuesto…

21cd437

…re API endpoint paths

surajmaurya-git requested a review from anedyasystems May 22, 2026 13:19

gemini-code-assist Bot reviewed May 22, 2026

View reviewed changes

feat: add dynamic transmit and receive buffers to client and implemen…

37ef6f3

…t payload size validation in response handler

anedyasystems requested changes May 22, 2026

View reviewed changes

Conversation

surajmaurya-git commented May 22, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

surajmaurya-git May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

surajmaurya-git May 22, 2026 •

edited

Loading