Added Custom Headers Logic to Query #9458
Conversation
WalkthroughThe changes in the Changes
Assessment against linked issues
Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/Utils/request/query.ts (2)
8-11: LGTM! Consider documenting the interface.The interface extension is well-designed and maintains backward compatibility. The
Record<string, string>type is appropriate for HTTP headers.Consider adding JSDoc comments to document the purpose and usage of this interface, especially since it's exported:
+/** + * Extends QueryOptions to support custom HTTP headers + * @template TBody - The type of the request body + */ export interface ExtendedQueryOptions<TBody> extends QueryOptions<TBody> { customHeaders?: Record<string, string>; }
61-62: LGTM! Consider improving type safety.The function signature update correctly incorporates the new ExtendedQueryOptions while maintaining existing functionality.
Consider making the signal parameter type more explicit:
-export default function query<TData, TBody>( +export default function query<TData, TBody, TError = unknown>( route: Route<TData, TBody>, options?: ExtendedQueryOptions<TBody>, -) { - return ({ signal }: { signal: AbortSignal }) => { +): (params: { signal: AbortSignal }) => Promise<TData> { + return ({ signal }) => { return queryRequest(route, { ...options, signal }); }; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/Utils/request/query.ts(2 hunks)
🔇 Additional comments (1)
src/Utils/request/query.ts (1)
14-15: Verify compatibility with existing query usages.
Since this changes the signature of a widely-used utility function, we should verify that existing usages remain compatible.
✅ Verification successful
Let me try a different search pattern since the previous one might have been too restrictive.
Based on the search results, I can now generate the final response:
The changes to the query function interface are safe and compatible
The codebase search reveals that all existing usages of the query function follow the updated interface pattern:
- All calls pass a route object as the first parameter
- The second
optionsparameter is consistently optional and matches theExtendedQueryOptionstype - The
Routetype is properly used across the codebase with consistent generic parameters
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all query function imports and usages
echo "Checking query function imports:"
rg -l "import.*query.*from.*['\"]@/Utils/request/query"
echo "\nChecking query function usages:"
ast-grep --pattern 'query({
$$$
})'
Length of output: 279
Script:
#!/bin/bash
# Search for query function imports with more relaxed pattern
echo "Checking query imports:"
rg "import.*query.*from.*['\"].*request" -A 2
echo "\nChecking direct query usages:"
rg "query\(" -A 2
# Also check for the Route type usage
echo "\nChecking Route type usage:"
rg "Route<" -A 2
Length of output: 4820
src/Utils/request/query.ts
Outdated
| // Merge customHeaders with default headers | ||
| const headers = { | ||
| ...makeHeaders(noAuth ?? false), | ||
| ...(options?.customHeaders || {}), | ||
| }; |
There was a problem hiding this comment.
Add validation for custom headers to prevent security issues.
While the header merging logic is correct, the lack of validation on custom headers could lead to security issues, especially since this is part of an OTP-based authentication flow.
Consider adding validation before merging headers:
+ // Validate custom headers to prevent injection
+ const sanitizeHeaders = (headers: Record<string, string>) => {
+ const sanitized: Record<string, string> = {};
+ for (const [key, value] of Object.entries(headers)) {
+ // Ensure header names and values follow RFC 7230
+ if (/^[!#$%&'*+-.^_`|~0-9a-zA-Z]+$/.test(key) &&
+ typeof value === 'string' &&
+ !value.includes('\n') &&
+ !value.includes('\r')) {
+ sanitized[key] = value;
+ }
+ }
+ return sanitized;
+ };
const headers = {
...makeHeaders(noAuth ?? false),
- ...(options?.customHeaders || {}),
+ ...sanitizeHeaders(options?.customHeaders || {}),
};Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Would using Headers obj. instead help prevent these security issues?
Back with references.
There was a problem hiding this comment.
@rithviknishad, using the Headers object can help manage HTTP headers more effectively, but it doesn't inherently prevent the security issues associated with unvalidated custom headers. The Headers interface enforces certain constraints on header names and values, which can reduce the risk of malformed headers. However, it doesn't automatically sanitize or validate header content against injection attacks or other security vulnerabilities.
Here's how you might use the Headers object:
const headers = new Headers(makeHeaders(noAuth ?? false));
if (options?.customHeaders) {
for (const [key, value] of Object.entries(options.customHeaders)) {
// Optional: Add validation logic here
headers.set(key, value);
}
}While this approach uses the Headers API, it's still important to validate or sanitize any custom headers to ensure they don't introduce security risks.
References:
src/Utils/request/query.ts
Outdated
| // Extend the QueryOptions interface to include customHeaders | ||
| export interface ExtendedQueryOptions<TBody> extends QueryOptions<TBody> { | ||
| customHeaders?: Record<string, string>; | ||
| } |
There was a problem hiding this comment.
The interface QueryOptions is defined exclusively for this itself. Feel free to move that interface here and directly add custom headers to that interface.
| // Extend the QueryOptions interface to include customHeaders | |
| export interface ExtendedQueryOptions<TBody> extends QueryOptions<TBody> { | |
| customHeaders?: Record<string, string>; | |
| } | |
| export interface ExtendedQueryOptions<TBody> extends QueryOptions<TBody> { | |
| headers?: HeadersInit; | |
| } |
There was a problem hiding this comment.
Made the changes as suggested
src/Utils/request/query.ts
Outdated
| // Merge customHeaders with default headers | ||
| const headers = { | ||
| ...makeHeaders(noAuth ?? false), | ||
| ...(options?.customHeaders || {}), | ||
| }; |
There was a problem hiding this comment.
We could modify the makeHeaders function directly to concat the headers through Headers obj. initialization itself.
| // Merge customHeaders with default headers | |
| const headers = { | |
| ...makeHeaders(noAuth ?? false), | |
| ...(options?.customHeaders || {}), | |
| }; | |
| const headers = makeHeaders(noAuth ?? false, additionalHeaders) |
There was a problem hiding this comment.
Made the changes as suggested
|
@srijantrpth I've also updated to include improved type-safety for the useQuery's error type. Pushed it along with this since it was a very minor piece. cc: @Jacobjeevan Before
After
|
|
@rithviknishad Kindly review the changes and let me know if you have any suggestions on improving the solution |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
src/Utils/request/query.ts (3)
17-33: Use the built-inHeadersclass for header management and validation.The custom
sanitizeHeadersfunction replicates functionality provided by theHeadersinterface, which automatically normalizes and validates header names and values according to the HTTP specification. UtilizingHeaderscan simplify the code and enhance reliability.Apply this diff to refactor the code:
-// Function to sanitize custom headers -const sanitizeHeaders = (headers: Record<string, string>) => { - const sanitized: Record<string, string> = {}; - for (const [key, value] of Object.entries(headers)) { - // Ensure header names follow RFC 7230 and values are safe - if ( - /^[!#$%&'*+-.^_`|~0-9a-zA-Z]+$/.test(key) && - typeof value === "string" && - !value.includes("\n") && - !value.includes("\r") - ) { - sanitized[key] = value; - } - } - return sanitized; -}; ... // Merge default headers with custom headers using Headers interface -const defaultHeaders = makeHeaders(noAuth ?? false); -const customHeaders = sanitizeHeaders(options?.customHeaders || {}); -const headers = { ...defaultHeaders, ...customHeaders }; // Merging headers manually +const headers = makeHeaders(noAuth ?? false, options?.customHeaders);This approach leverages the
Headersclass's built-in validation and simplifies header merging.
42-44: Avoid manual header merging; delegate tomakeHeadersfunction.Manually merging headers can lead to inconsistent behavior. Since
makeHeadersalready supports additional headers, you can passoptions?.customHeadersdirectly to it.Apply this change:
-const defaultHeaders = makeHeaders(noAuth ?? false); -const customHeaders = sanitizeHeaders(options?.customHeaders || {}); -const headers = { ...defaultHeaders, ...customHeaders }; // Merging headers manually +const headers = makeHeaders(noAuth ?? false, options?.customHeaders);This ensures consistent header creation and leverages existing utility functions.
85-86: Update the generic type parameters for consistency and clarity.Ensure that the generic type parameters
TDataandTBodyare consistently applied in thequeryfunction signature.Review and confirm that the usage aligns with intended types. No code changes are necessary if types are correctly applied.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/Utils/request/query.ts(2 hunks)src/Utils/request/types.ts(1 hunks)src/Utils/request/utils.ts(1 hunks)
🔇 Additional comments (1)
src/Utils/request/types.ts (1)
44-44: Redundant headers property in QueryOptions.
The headers?: HeadersInit; property addition to QueryOptions may be unnecessary if custom headers are managed via customHeaders or passed directly to makeHeaders.
This concern is similar to the previous suggestion about simplifying header management.
src/Utils/request/query.ts
Outdated
| export interface QueryOptionsWithHeaders<TBody> extends QueryOptions<TBody> { | ||
| customHeaders?: Record<string, string>; | ||
| headers?: HeadersInit; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider extending existing QueryOptions instead of creating a new interface.
The addition of QueryOptionsWithHeaders<TBody> introduces redundancy since headers have already been added to QueryOptions<TBody> in types.ts. You can simplify the code by using QueryOptions<TBody> directly and removing QueryOptionsWithHeaders<TBody>.
Apply this diff to remove the redundant interface:
-/**
- * Extend the QueryOptions interface to include customHeaders
- * @template TBody - The type of the request body
- */
-export interface QueryOptionsWithHeaders<TBody> extends QueryOptions<TBody> {
- customHeaders?: Record<string, string>;
- headers?: HeadersInit;
-}And update the function signatures accordingly:
async function queryRequest<TData, TBody>(
{ path, method, noAuth }: Route<TData, TBody>,
- options?: QueryOptionsWithHeaders<TBody>,
+ options?: QueryOptions<TBody>,
): Promise<TData> { ... }
export default function query<TData, TBody>(
route: Route<TData, TBody>,
- options?: QueryOptionsWithHeaders<TBody>,
+ options?: QueryOptions<TBody>,
): (params: { signal: AbortSignal }) => Promise<TData> { ... }There was a problem hiding this comment.
@srijantrpth, thank you for fixing it!
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
|
I think the santizie headers is an overkill. Since we are anyways not going to take user input for setting the header values. cc: @Jacobjeevan |
|
@rithviknishad So should we remove the sanitizeHeaders? |
yep |
Ok, I am implementing the overwriting in the headers. |
…rwriting, and resolve type conflicts
|
@rithviknishad Something is wrong with cypress tests maybe there's a version mismatch |
|
@rithviknishad Something is wrong with cypress tests due to version maybe due to the version |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/Utils/request/query.ts (1)
Line range hint
47-51: Improve error handling with more specific error messages.The current generic "Network Error" message doesn't provide enough context about what went wrong.
Consider enhancing the error handling:
try { res = await fetch(url, fetchOptions); } catch (error) { - throw new Error("Network Error"); + throw new QueryError({ + message: error instanceof Error ? error.message : "Network Error", + status: 0, + silent: options?.silent ?? false, + cause: { type: "network_error", details: error }, + }); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/Utils/request/query.ts(1 hunks)
🔇 Additional comments (1)
src/Utils/request/query.ts (1)
30-34: Verify the impact of header changes across the codebase.
The changes to header handling might affect existing code that relies on the previous behavior.
Let's verify the usage:
src/Utils/request/query.ts
Outdated
| export interface QueryOptions<TBody> { | ||
| body?: TBody; | ||
| queryParams?: Record<string, any>; | ||
| pathParams?: Record<string, any>; | ||
| silent?: boolean; | ||
| signal?: AbortSignal; | ||
| headers?: Record<string, string>; // Add headers support | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use HeadersInit type for better compatibility with the Fetch API.
The headers property type should be HeadersInit instead of Record<string, string> for better compatibility with the Fetch API's Headers interface.
Apply this diff:
export interface QueryOptions<TBody> {
body?: TBody;
queryParams?: Record<string, any>;
pathParams?: Record<string, any>;
silent?: boolean;
signal?: AbortSignal;
- headers?: Record<string, string>; // Add headers support
+ headers?: HeadersInit; // Add headers support
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export interface QueryOptions<TBody> { | |
| body?: TBody; | |
| queryParams?: Record<string, any>; | |
| pathParams?: Record<string, any>; | |
| silent?: boolean; | |
| signal?: AbortSignal; | |
| headers?: Record<string, string>; // Add headers support | |
| } | |
| export interface QueryOptions<TBody> { | |
| body?: TBody; | |
| queryParams?: Record<string, any>; | |
| pathParams?: Record<string, any>; | |
| silent?: boolean; | |
| signal?: AbortSignal; | |
| headers?: HeadersInit; // Add headers support | |
| } |
src/Utils/request/query.ts
Outdated
| // Convert Headers object to a plain object | ||
| const defaultHeaders = Object.fromEntries( | ||
| makeHeaders(noAuth ?? false).entries(), | ||
| ); | ||
|
|
||
| // Merge default headers with custom headers, with custom headers taking precedence | ||
| const headers = { | ||
| ...defaultHeaders, | ||
| ...(options?.headers || {}), | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve header handling using the Headers API.
The current implementation converts Headers to a plain object and then merges them, which:
- Loses the built-in validation and normalization of the Headers API
- Makes it harder to handle multiple values for the same header
Consider using the Headers API directly:
- // Convert Headers object to a plain object
- const defaultHeaders = Object.fromEntries(
- makeHeaders(noAuth ?? false).entries(),
- );
-
- // Merge default headers with custom headers, with custom headers taking precedence
- const headers = {
- ...defaultHeaders,
- ...(options?.headers || {}),
- };
+ // Use Headers API for better header management
+ const headers = new Headers(makeHeaders(noAuth ?? false));
+
+ // Merge custom headers
+ if (options?.headers) {
+ const customHeaders = new Headers(options.headers);
+ customHeaders.forEach((value, key) => {
+ headers.set(key, value);
+ });
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Convert Headers object to a plain object | |
| const defaultHeaders = Object.fromEntries( | |
| makeHeaders(noAuth ?? false).entries(), | |
| ); | |
| // Merge default headers with custom headers, with custom headers taking precedence | |
| const headers = { | |
| ...defaultHeaders, | |
| ...(options?.headers || {}), | |
| }; | |
| // Use Headers API for better header management | |
| const headers = new Headers(makeHeaders(noAuth ?? false)); | |
| // Merge custom headers | |
| if (options?.headers) { | |
| const customHeaders = new Headers(options.headers); | |
| customHeaders.forEach((value, key) => { | |
| headers.set(key, value); | |
| }); | |
| } |
There was a problem hiding this comment.
Is there any performance overhead introduced by using the Headers API compared to a plain object?
There was a problem hiding this comment.
@srijantrpth, using the Headers API introduces minimal performance overhead compared to using a plain object. The Headers API is optimized for managing HTTP headers efficiently, and it provides benefits like built-in normalization and validation. These features enhance the robustness of header handling without significantly impacting performance. In most cases, the slight overhead is negligible and is outweighed by the advantages in code maintainability and correctness.
If performance is a critical concern, we can consider benchmarking both implementations to measure any differences. However, it's unlikely to be a bottleneck under normal circumstances.
There was a problem hiding this comment.
Is it used across all our environments? If yes, let me rectify it else it's fine
There was a problem hiding this comment.
@srijantrpth, the Headers API is indeed used in our codebase. Specifically, in src/Utils/request/utils.ts, we create headers using the Headers API:
const headers = new Headers({
"Content-Type": "application/json",
Accept: "application/json",
...additionalHeaders,
});Using the Headers API in your implementation would maintain consistency across all our environments. It would be beneficial to adopt it for better header management.
🔗 Analysis chain
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usages of the Headers API in the codebase
ast-grep --pattern 'new Headers($_)'
Length of output: 324
There was a problem hiding this comment.
Ok, let me rectify the code
There was a problem hiding this comment.
@srijantrpth, glad to hear you're updating the code! Let me know if you need any assistance.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
src/Utils/request/query.ts
Outdated
| export interface QueryOptions<TBody> { | ||
| body?: TBody; | ||
| queryParams?: Record<string, any>; | ||
| pathParams?: Record<string, any>; | ||
| silent?: boolean; | ||
| signal?: AbortSignal; | ||
| headers?: Record<string, string>; // Add headers support | ||
| } |
There was a problem hiding this comment.
let's not duplicate the type. this is already present in request/types.ts
src/Utils/request/query.ts
Outdated
| // Convert Headers object to a plain object | ||
| const defaultHeaders = Object.fromEntries( | ||
| makeHeaders(noAuth ?? false).entries(), | ||
| ); | ||
|
|
||
| // Merge default headers with custom headers, with custom headers taking precedence | ||
| const headers = { | ||
| ...defaultHeaders, | ||
| ...(options?.headers || {}), | ||
| }; | ||
|
|
There was a problem hiding this comment.
I guess you may be confused about the objective. This would "overwrite" the headers. But the intended behaviour is to "append" the headers while preserving the previously set headers.
Let's stick with using the Headers API. It's there for a purpose :) -- best practices
Refer: https://developer.mozilla.org/en-US/docs/Web/API/Headers/append
There was a problem hiding this comment.
I am sorry about that, I'll fix this and let you know
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/Utils/request/query.ts (1)
5-17:⚠️ Potential issueRemove duplicate interface definition and use existing
QueryOptionsfrom types.ts.The local
QueryOptionsinterface definition creates unnecessary duplication and reduces type safety. Previous reviews have already addressed this:
- The interface already exists in
types.ts- The
headersproperty should useHeadersInittype for better Fetch API compatibilityApply this diff to fix the issues:
import { Route } from "@/Utils/request/types"; -// Remove conflicting QueryOptions import +import { QueryOptions } from "@/Utils/request/types"; import { makeHeaders, makeUrl } from "@/Utils/request/utils"; -// Define QueryOptions locally, including the 'headers' property -export interface QueryOptions<TBody> { - body?: TBody; - queryParams?: Record<string, any>; - pathParams?: Record<string, any>; - silent?: boolean; - signal?: AbortSignal; - headers?: Record<string, string>; // Add headers support -}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/Utils/request/query.ts(1 hunks)
🔇 Additional comments (1)
src/Utils/request/query.ts (1)
37-40: LGTM! Proper usage of Headers API in fetch options.
The implementation correctly uses the Headers object in the fetch options and properly handles the abort signal.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/Utils/request/query.ts(1 hunks)src/Utils/request/utils.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/Utils/request/query.ts
🧰 Additional context used
📓 Learnings (1)
src/Utils/request/utils.ts (1)
Learnt from: rithviknishad
PR: ohcnetwork/care_fe#9458
File: src/Utils/request/utils.ts:61-64
Timestamp: 2024-12-16T13:40:33.928Z
Learning: The application does not use server-side rendering, so directly accessing `localStorage` is acceptable.
🔇 Additional comments (3)
src/Utils/request/utils.ts (3)
53-53: LGTM: Function signature properly updated for custom headers support
The addition of the optional additionalHeaders parameter with HeadersInit type is appropriate for the custom headers requirement.
60-63: LGTM: Token retrieval and authorization header handling
The implementation correctly:
- Retrieves the token from localStorage (confirmed acceptable as per team's clarification about no SSR)
- Properly formats and sets the Bearer token
53-63: Verify integration with query functionality
Let's ensure the header changes work correctly with the query implementation.
✅ Verification successful
Based on the results, I can generate the final response as we have clear evidence of the integration:
Header changes are properly integrated with query functionality
The makeHeaders function is correctly used across the request utilities:
- In
query.ts: Used to set headers in query options - In
request.ts: Applied to request options before fetch - No conflicting header manipulations found elsewhere
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of makeHeaders to verify integration
rg -A 3 "makeHeaders\(" --type ts
# Look for any direct Headers manipulation that might conflict
rg -A 3 "new Headers\(" --type ts
Length of output: 1047
|
@Jacobjeevan Please review the latest changes and let me know if any changes are required. |
|
@srijantrpth Your efforts have helped advance digital healthcare and TeleICU systems. 🚀 Thank you for taking the time out to make CARE better. We hope you continue to innovate and contribute; your impact is immense! 🙌 |
Proposed Changes
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit