feat: File Upload (Amazon S3) app

[miguelnietoa]

What does this PR do?

Maybe this is not the best implementation but I decided to give it a try since I didn't see any progress 😄

Fixes #6939 /claim #6939

https://www.loom.com/share/b8a0d309ab404d1d990086bc53cbef58

Environment: Staging(main branch) / Production

Type of change

• New feature (non-breaking change which adds functionality)

How should this be tested?

• [ ] Test A
• [ ] Test B

Checklist

• I haven't checked if my PR needs changes to the documentation
• I haven't added tests that prove my fix is effective or that my feature works

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 29, 2023 2:10pm

[vercel[bot]]

@miguelnietoa is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions[bot]]

📦 Next.js Bundle Analysis for @calcom/web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

⚠️ Global Bundle Size Increased

Page	Size (compressed)
global	210.5 KB (🔴 +56.41 KB)

Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

New Pages Added

The following pages were added to the bundle from the code in this PR:

Page	Size (compressed)	First Load	% of Budget (350 KB)
/[user]/book	611.36 KB	821.87 KB	234.82%
/[user]/calendar-cache/[month]	332 B	210.83 KB	60.24%
/d/[link]/[slug]/embed	99.42 KB	309.92 KB	88.55%
/d/[link]/book	611.02 KB	821.52 KB	234.72%
/team/[slug]/book	611.02 KB	821.52 KB	234.72%

Seventy-five Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load	% of Budget (350 KB)
/404	8.34 KB	218.84 KB	62.52% (🟢 -23.84%)
/500	5.96 KB	216.46 KB	61.85% (🟢 -23.67%)
/[user]	111.33 KB	321.83 KB	91.95% (🟡 +3.68%)
/[user]/[type]	99.74 KB	310.25 KB	88.64% (🟢 -84.79%)
/[user]/[type]/embed	99.77 KB	310.27 KB	88.65% (🟢 -84.80%)
/[user]/embed	111.4 KB	321.9 KB	91.97% (🟡 +3.69%)
/_error	36.57 KB	247.07 KB	70.59% (🟡 +2.36%)
/apps	170.96 KB	381.46 KB	108.99% (🟢 -28.29%)
/apps/[slug]	194.58 KB	405.08 KB	115.74% (🟢 -26.69%)
/apps/[slug]/[...pages]	395.16 KB	605.66 KB	173.05% (🟢 -62.43%)
/apps/[slug]/setup	923 B	211.4 KB	60.40% (🟢 -25.22%)
/apps/categories	155.83 KB	366.33 KB	104.66% (🟢 -26.64%)
/apps/categories/[category]	159.72 KB	370.22 KB	105.78% (🟢 -26.70%)
/apps/installed/[category]	198.94 KB	409.44 KB	116.98% (🟢 -20.11%)
/auth/error	19.21 KB	229.72 KB	65.63% (🟢 -23.63%)
/auth/forgot-password	25.56 KB	236.06 KB	67.45% (🟢 -31.61%)
/auth/forgot-password/[id]	40.88 KB	251.38 KB	71.82% (🟢 -27.04%)
/auth/login	40.03 KB	250.53 KB	71.58% (🟢 -31.94%)
/auth/logout	7.54 KB	218.04 KB	62.30% (🟢 -23.64%)
/auth/saml-idp	400 B	210.89 KB	60.25% (🟢 -23.65%)
/auth/setup	103.51 KB	314.01 KB	89.72% (🟢 -20.11%)
/auth/signin	474 B	210.96 KB	60.28% (🟢 -23.66%)
/auth/sso/[provider]	540 B	211.03 KB	60.29% (🟢 -23.65%)
/auth/sso/direct	422 B	210.91 KB	60.26% (🟢 -23.66%)
/auth/verify	18.19 KB	228.69 KB	65.34% (🟢 -23.63%)
/availability	159.03 KB	369.53 KB	105.58% (🟢 -27.31%)
/availability/[schedule]	272.03 KB	482.53 KB	137.87% (🟢 -22.69%)
/availability/troubleshoot	156.51 KB	367.01 KB	104.86% (🟢 -26.66%)
/booking/[uid]	131.42 KB	341.92 KB	97.69% (🟢 -54.49%)
/bookings/[status]	266.28 KB	476.78 KB	136.22% (🟢 -21.79%)
/d/[link]/[slug]	99.39 KB	309.89 KB	88.54% (🟢 -84.90%)
/event-types	351.91 KB	562.42 KB	160.69% (🟢 -69.04%)
/event-types/[type]	392.57 KB	603.07 KB	172.30% (🟢 -24.27%)
/getting-started/[[...step]]	329.79 KB	540.3 KB	154.37% (🟢 -20.78%)
/maintenance	628 B	211.11 KB	60.32% (🟢 -23.66%)
/more	155.45 KB	365.95 KB	104.56% (🟢 -26.65%)
/payment/[uid]	68.78 KB	279.28 KB	79.79% (🟢 -15.50%)
/settings/admin	160.88 KB	371.38 KB	106.11% (🟢 -26.75%)
/settings/admin/apps	193.86 KB	404.36 KB	115.53% (🟢 -20.85%)
/settings/admin/apps/[category]	193.84 KB	404.34 KB	115.53% (🟢 -20.85%)
/settings/admin/impersonation	161.16 KB	371.66 KB	106.19% (🟢 -26.75%)
/settings/billing	161.07 KB	371.57 KB	106.16% (🟢 -26.74%)
/settings/developer/api-keys	190.15 KB	400.65 KB	114.47% (🟢 -19.72%)
/settings/developer/webhooks	163.48 KB	373.98 KB	106.85% (🟢 -27.20%)
/settings/developer/webhooks/[id]	192.39 KB	402.89 KB	115.11% (🟢 -19.32%)
/settings/developer/webhooks/new	192.25 KB	402.75 KB	115.07% (🟢 -19.33%)
/settings/my-account/appearance	174.95 KB	385.45 KB	110.13% (🟢 -28.43%)
/settings/my-account/calendars	193.26 KB	403.76 KB	115.36% (🟢 -19.35%)
/settings/my-account/conferencing	166.75 KB	377.25 KB	107.79% (🟢 -26.79%)
/settings/my-account/general	266.22 KB	476.72 KB	136.20% (🟢 -21.12%)
/settings/my-account/profile	428.08 KB	638.58 KB	182.45% (🟡 +13.40%)
/settings/security/impersonation	163.03 KB	373.53 KB	106.72% (🟢 -26.89%)
/settings/security/password	194.43 KB	404.93 KB	115.69% (🟢 -21.27%)
/settings/security/sso	170.7 KB	381.2 KB	108.92% (🟢 -26.64%)
/settings/security/two-factor-auth	165.48 KB	375.98 KB	107.42% (🟢 -26.93%)
/settings/teams	160.62 KB	371.12 KB	106.03% (🟢 -26.75%)
/settings/teams/[id]/appearance	174.98 KB	385.48 KB	110.14% (🟢 -25.43%)
/settings/teams/[id]/billing	160.86 KB	371.36 KB	106.10% (🟢 -26.76%)
/settings/teams/[id]/members	297.87 KB	508.37 KB	145.25% (🟢 -22.31%)
/settings/teams/[id]/onboard-members	74.1 KB	284.6 KB	81.31% (🟢 -26.61%)
/settings/teams/[id]/profile	273.26 KB	483.76 KB	138.22% (🟢 -49.12%)
/settings/teams/[id]/sso	170.8 KB	381.3 KB	108.94% (🟢 -26.63%)
/settings/teams/new	113.33 KB	323.83 KB	92.52% (🟢 -22.10%)
/signup	25.42 KB	235.92 KB	67.41% (🟢 -34.95%)
/team/[slug]	113.78 KB	324.28 KB	92.65% (🟢 -32.62%)
/team/[slug]/[type]	99.39 KB	309.89 KB	88.54% (🟢 -84.90%)
/team/[slug]/[type]/embed	99.43 KB	309.93 KB	88.55% (🟢 -84.90%)
/team/[slug]/embed	113.84 KB	324.34 KB	92.67% (🟢 -32.61%)
/teams	155.67 KB	366.17 KB	104.62% (🟢 -26.63%)
/video/[uid]	34.65 KB	245.16 KB	70.04% (🟢 -58.55%)
/video/meeting-ended/[uid]	22.74 KB	233.24 KB	66.64% (🟢 -21.21%)
/video/meeting-not-started/[uid]	22.79 KB	233.29 KB	66.66% (🟢 -21.10%)
/video/no-meeting-found	6.95 KB	217.46 KB	62.13% (🟢 -23.41%)
/workflows	168.56 KB	379.07 KB	108.30% (🟢 -32.92%)
/workflows/[workflow]	296.56 KB	507.06 KB	144.87% (🟢 -28.44%)

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/-

[rjackson]

I’ve been similarly interested in this app due to the lack of progress on the issue 😄

One major issue that I noticed with the idea for the app, that I think your implementation also suffers from, is that anything stored in ‘appData’ (or the ‘metadata’ column in the database, if I remember correctly) is stored in plaintext and exposed to the browser.

For most apps I don’t think that’s a problem, for this app - where we’re storing third party Amazon API keys - it’s a big one. Any bookee could exfiltrate these API keys via “View Source” 😬

‘appKeys’ might be a better place to store these keys, but then they’ll be shared across all instances of the file upload app; not varied per event type, and not as easy to manage from the UI.

I’ve been thinking about wider changes to make a public/private split of ‘appData’, where private entries are encrypted at rest and not exposed to browsers at all; they can only be used server-side (app settings card being the only, authenticated, exception of course).

Thought I’d best flag this in case you have any thoughts, or perhaps you’ve already solved this and I just haven’t spotted how. Happy to keep exploring my thoughts on this and work together on a solution if that might be helpful?

[miguelnietoa]

Hey @rjackson 👋🏻

I totally agree with you. The appData being stored in plaintext is currently a significant security issue.

I just uploaded the PR to ask for feedback, and of course, we could work together!

I think I have a solution, which is to use symmetricEncrypt and symmetricDecrypt. The API Keys are encrypted/decrypted using the CALENDSO_ENCRYPTION_KEY env var, and that's it.

This way the API Keys are stored directly in the eventType metadata but encrypted. What do you think about this idea?

[hariombalhara]

Just thinking out loud, haven't gone into much detail but saw the comment and thought to jump in. There are credentials per user that are stored in the Credential table. In this case, we want to store Credential per EventType, maybe we can update the Credential schema to accommodate that.

There is one drawback with that the size of Credential was earlier increasing by per user, now it will increase by per user X eventType.

We can also think about creating a different Credential table just for EventType credentials. That can be useful because the EventTypeCredentials table would be pretty lightweight and the queries would be faster on it which we might need during the booking flow(keeping in mind that we want to keep that flow blazingly fast).

cc @keithwillcode @emrysal @zomars

[github-actions[bot]]

This PR is being marked as stale due to inactivity.

[github-actions[bot]]

This PR is being closed due to inactivity. Please reopen if work is intended to be continued.

[github-actions[bot]]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Details:

No release type found in pull request title "[WIP] feat: File Upload (Amazon S3) app". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:
 - feat: A new feature
 - fix: A bug fix
 - docs: Documentation only changes
 - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
 - refactor: A code change that neither fixes a bug nor adds a feature
 - perf: A code change that improves performance
 - test: Adding missing tests or correcting existing tests
 - build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
 - ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 - chore: Other changes that don't modify src or test files
 - revert: Reverts a previous commit

[github-actions[bot]]

This PR is being marked as stale due to inactivity.

[github-actions[bot]]

This PR is being closed due to inactivity. Please reopen if work is intended to be continued.