feat: Add user's avatar to POST and PATCH requests in users endpoints#11187
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@HamzaFouad is attempting to deploy a commit to the cal Team on Vercel. A member of the Team first needs to authorize it. |
|
Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link to collect XP and win prizes! |
📦 Next.js Bundle Analysis for @calcom/webThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
|
This PR is being marked as stale due to inactivity. |
| try { | ||
| let base64Data = input; | ||
| // Check if the input starts with a data URI scheme (data:content/type;base64,...) | ||
| if (input.startsWith("data:")) { | ||
| const parts = input.split(","); | ||
| if (parts.length === 2) { | ||
| // metadata and base64Data | ||
| base64Data = parts[1]; // Extract the base64 data from the second part | ||
| } | ||
| } | ||
| const buffer = Buffer.from(base64Data, "base64").toString("base64"); | ||
| return buffer === base64Data; | ||
| } catch (error) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
couldn't we replace this whole thing with a regexp ?
Also I think the naming of the function is unclear, we are here checking if the data inside of the data-uri string is encoded in base64.
There was a problem hiding this comment.
Sure we can. but why do yo prefer using regex over a native lib?
I tried to name the extension method to be as generic as possible to accommodate all base64-encoding-string checks, not just for images.
|
@alishaz-polymath Could you please take the initiative and help this PR to move forward? It has been stale for very long time with no progress in reviews. |
I'll review it this week. Thank you @HamzaFouad 🙏 |
alishaz-polymath
left a comment
There was a problem hiding this comment.
Requested a few changes to improve strictness and efficiency.
Please do test locally to confirm they work and adjust accordingly. The rest looks good to me 🎉 , but I'll wait on the requested changes. 🙏
| @@ -0,0 +1,17 @@ | |||
| export function isValidBase64(input: string): boolean { | |||
| try { | |||
There was a problem hiding this comment.
| try { | |
| const base64Regex = /^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/; | |
| try { |
Can potentially use a regex here for strict checking for base64
This pattern assumes a character set of A-Z, a-z, 0-9, +, / and possibly ending with = or ==.
| if (parts.length === 2) { | ||
| // metadata and base64Data | ||
| base64Data = parts[1]; // Extract the base64 data from the second part | ||
| } |
There was a problem hiding this comment.
| if (parts.length === 2) { | |
| // metadata and base64Data | |
| base64Data = parts[1]; // Extract the base64 data from the second part | |
| } | |
| if (parts.length !== 2) return false; | |
| base64Data = parts[1]; // Extract the base64 data from the second part |
We can return false when parts length !== 2 to not go about further computations as it would be false already.
There was a problem hiding this comment.
I made this condition to not just cover base64-images, but also to cover any base64 string checks you might have in the app, so the string may be a single part or multiple part based on the usecase.
if we are only going to make this method exclusive to base64-images then there is no need for the above check
and we can tweak the regex you implemented and implement the method similar to that:
export function isValidBase64Image(input: string): boolean {
const regex = /^data:image\/[^;]+;base64,(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/;
return regex.test(input);
}
we will also rename the method to be image exclusive isValidBase64Image
| base64Data = parts[1]; // Extract the base64 data from the second part | ||
| } | ||
| } | ||
| const buffer = Buffer.from(base64Data, "base64").toString("base64"); |
There was a problem hiding this comment.
| const buffer = Buffer.from(base64Data, "base64").toString("base64"); | |
| if (!base64Regex.test(base64Data)) return false; | |
| Buffer.from(base64Data, "base64"); | |
| return true; |
We can use regex to test and return false if it doesn't adhere to the regex pattern. The next line would fail if not base64, at which point it should return false thanks to catch.
There was a problem hiding this comment.
I think we no longer need to use this line too anymore, right?
Buffer.from(base64Data, "base64");
as the condition before it should be enough to cover base64 validity
There was a problem hiding this comment.
Actually we still do.
- The regex test checks if the string looks like valid base64
- The buffer conversion checks if the string can be successfully decoded as base64
There was a problem hiding this comment.
how so?
if it is a valid base64 string, then by definition, it can be decoded into binary data. Or am I missing something?
if we needed to use Buffer.from(base64Data, "base64") then why do we need the regex check at all.
we could have passed the string to the buffer, as I did at first, and if it is decodable then it passes the validation and if not we catch the exception and return false.
There was a problem hiding this comment.
@ThyMinimalDev
What do you think?
The regex is fairly strict so there shouldn't be many strings that pass the regex and fail Base64, but what is the safer approach here?
There was a problem hiding this comment.
I Think using a regexp is the best approach here, I don't think there is a bulletproof way to make sure that the base64 string is actually a valid image, but as long as it's a valid base64 it is fine.
| } | ||
| } | ||
| const buffer = Buffer.from(base64Data, "base64").toString("base64"); | ||
| return buffer === base64Data; |
There was a problem hiding this comment.
| return buffer === base64Data; | |
Don't need to recheck it now that all checks are already done, this is redundant.
…HamzaFouad/cal.com into api/user-avatar-post-and-patch-requests
| import { _UserModel as User } from "@calcom/prisma/zod"; | ||
| import { iso8601 } from "@calcom/prisma/zod-utils"; | ||
|
|
||
| import { isValidBase64Image } from "~/lib/utils/isValidBase64"; |
There was a problem hiding this comment.
missed this during review, this file is now named isValidBase64Image.ts not isValidBase64.ts
…#11187) Co-authored-by: Syed Ali Shahbaz <52925846+alishaz-polymath@users.noreply.github.com> Co-authored-by: Peer Richelsen <peeroke@gmail.com> ## What does this PR do? <!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. --> Fix wrong import introduced in this pr: #11187 <!-- Please provide a loom video for visual changes to speed up reviews Loom Video: https://www.loom.com/ --> ## Requirement/Documentation <!-- Please provide all documents that are important to understand the reason of that PR. --> - If there is a requirement document, please, share it here. - If there is ab UI/UX design document, please, share it here. ## Type of change <!-- Please delete bullets that are not relevant. --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Chore (refactoring code, technical debt, workflow improvements) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How should this be tested? <!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Write details that help to start the tests --> - Are there environment variables that should be set? - What are the minimal test data to have? - What is expected (happy path) to have (input and output)? - Any other important info that could help to test that PR ## Mandatory Tasks - [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected. ## Checklist <!-- Remove bullet points below that don't apply to you --> - I haven't read the [contributing guide](https://github.com/calcom/cal.com/blob/main/CONTRIBUTING.md) - My code doesn't follow the style guidelines of this project - I haven't commented my code, particularly in hard-to-understand areas - I haven't checked if my PR needs changes to the documentation - I haven't checked if my changes generate no new warnings - I haven't added tests that prove my fix is effective or that my feature works - I haven't checked if new and existing unit tests pass locally with my changes
…#11187) (#12256) Co-authored-by: Syed Ali Shahbaz <52925846+alishaz-polymath@users.noreply.github.com> Co-authored-by: Peer Richelsen <peeroke@gmail.com> ## What does this PR do? <!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. --> Fix wrong import introduced in this pr: #11187 <!-- Please provide a loom video for visual changes to speed up reviews Loom Video: https://www.loom.com/ --> ## Requirement/Documentation <!-- Please provide all documents that are important to understand the reason of that PR. --> - If there is a requirement document, please, share it here. - If there is ab UI/UX design document, please, share it here. ## Type of change <!-- Please delete bullets that are not relevant. --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Chore (refactoring code, technical debt, workflow improvements) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How should this be tested? <!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Write details that help to start the tests --> - Are there environment variables that should be set? - What are the minimal test data to have? - What is expected (happy path) to have (input and output)? - Any other important info that could help to test that PR ## Mandatory Tasks - [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected. ## Checklist <!-- Remove bullet points below that don't apply to you --> - I haven't read the [contributing guide](https://github.com/calcom/cal.com/blob/main/CONTRIBUTING.md) - My code doesn't follow the style guidelines of this project - I haven't commented my code, particularly in hard-to-understand areas - I haven't checked if my PR needs changes to the documentation - I haven't checked if my changes generate no new warnings - I haven't added tests that prove my fix is effective or that my feature works - I haven't checked if new and existing unit tests pass locally with my changes
…#11187) Co-authored-by: Syed Ali Shahbaz <52925846+alishaz-polymath@users.noreply.github.com> Co-authored-by: Peer Richelsen <peeroke@gmail.com>
…#11187) (#12256) Co-authored-by: Syed Ali Shahbaz <52925846+alishaz-polymath@users.noreply.github.com> Co-authored-by: Peer Richelsen <peeroke@gmail.com> ## What does this PR do? <!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. --> Fix wrong import introduced in this pr: #11187 <!-- Please provide a loom video for visual changes to speed up reviews Loom Video: https://www.loom.com/ --> ## Requirement/Documentation <!-- Please provide all documents that are important to understand the reason of that PR. --> - If there is a requirement document, please, share it here. - If there is ab UI/UX design document, please, share it here. ## Type of change <!-- Please delete bullets that are not relevant. --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Chore (refactoring code, technical debt, workflow improvements) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How should this be tested? <!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Write details that help to start the tests --> - Are there environment variables that should be set? - What are the minimal test data to have? - What is expected (happy path) to have (input and output)? - Any other important info that could help to test that PR ## Mandatory Tasks - [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected. ## Checklist <!-- Remove bullet points below that don't apply to you --> - I haven't read the [contributing guide](https://github.com/calcom/cal.com/blob/main/CONTRIBUTING.md) - My code doesn't follow the style guidelines of this project - I haven't commented my code, particularly in hard-to-understand areas - I haven't checked if my PR needs changes to the documentation - I haven't checked if my changes generate no new warnings - I haven't added tests that prove my fix is effective or that my feature works - I haven't checked if new and existing unit tests pass locally with my changes
What does this PR do?
POSTandPATCHrequests in users endpointRequirement/Documentation
Type of change
How should this be tested?
Mandatory Tasks
Checklist