Skip to content

fix: UID cookie isn't accessible/created when in embed as it is third party context.#19859

Merged
anikdhabal merged 2 commits into
calcom:mainfrom
codex-maintainers:gopoto/19616
Mar 18, 2025
Merged

fix: UID cookie isn't accessible/created when in embed as it is third party context.#19859
anikdhabal merged 2 commits into
calcom:mainfrom
codex-maintainers:gopoto/19616

Conversation

@codex-maintainers
Copy link
Copy Markdown
Contributor

What does this PR do?

We currently use a uid cookie to both mark a reserved slot and gate the “Slot no longer available” rollout. On embeds, however, that cookie never gets set because SameSite=Lax cookies aren’t sent from <iframe>s and other third‑party contexts. This has two side–effects:

  • Every slot a user clicks in an embed ends up blocked for everybody else because each reserveSlot call gets a fresh uid and we never “unlink” the previous provisional selection.
  • We can’t roll out “Slot no longer available” on embeds because the feature flag requires the visitor to have a cookie.

This patch sets the uid cookie to SameSite=None; Secure in production (WEBAPP_URL starts with https://) and gracefully falls back to SameSite=Lax locally so you can still develop on http://localhost. Safari will still need special handling, but moving to SameSite=None unblocks Chrome and other major browsers.

A small unit test has been added under packages/trpc/server/routers/viewer/slots to exercise that the cookie emitted by reserveSlotHandler picks up the right security flags for both HTTP and HTTPS environments.

Mandatory Tasks (DO NOT REMOVE)

  • I have self-reviewed the code (A decent size PR without self-review might be rejected).
  • I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
  • I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

  1. Run under an HTTPS WEBAPP_URL (or point NEXT_PUBLIC_WEBAPP_URL at an HTTPS origin).
  2. Embed a booking page in a separate site and select a slot.
  3. Open the browser’s cookie inspector inside the iframe: the uid cookie should now be present with SameSite=None and Secure set.
  4. Click multiple timeslots – only your last selection should remain blocked for other visitors, and Quick Availability checks can be rolled out to embeds because uid is now visible.

For local development (http://localhost:3000), cookies continue to be SameSite=Lax/non‑secure so you won’t be forced to configure HTTPS.

@vercel
Copy link
Copy Markdown

vercel Bot commented Mar 7, 2025

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

A member of the Team first needs to authorize it.

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Mar 7, 2025

CLA assistant check
All committers have signed the CLA.

@github-actions github-actions Bot added embed area: embed, widget, react embed enterprise area: enterprise, audit log, organisation, SAML, SSO 🐛 bug Something isn't working labels Mar 7, 2025
// We need this cookie to be accessible from embeds where the booking flow is displayed within an iframe on a different origin.
// For third‑party iframe contexts (embeds on other sites), browsers require SameSite=None and Secure to make the cookie available.
// For local development on http://localhost we fall back to SameSite=Lax to avoid requiring https during development.
const useSecureCookies = WEBAPP_URL?.startsWith("https://");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think WEBAPP_URL could be undefined

Suggested change
const useSecureCookies = WEBAPP_URL?.startsWith("https://");
const useSecureCookies = WEBAPP_URL.startsWith("https://");

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropped the optional chain on WEBAPP_URL — it always has a value so we can safely call startsWith.

Comment thread packages/trpc/server/routers/viewer/slots/reserveSlot.handler.ts
@codex-maintainers codex-maintainers marked this pull request as ready for review March 11, 2025 20:52
@codex-maintainers codex-maintainers requested a review from a team as a code owner March 11, 2025 20:52
@graphite-app graphite-app Bot added the community Created by Linear-GitHub Sync label Mar 11, 2025
@graphite-app graphite-app Bot requested a review from a team March 11, 2025 20:52
@graphite-app
Copy link
Copy Markdown

graphite-app Bot commented Mar 11, 2025

Graphite Automations

"Add consumer team as reviewer" took an action on this PR • (03/11/25)

1 reviewer was added to this PR based on Keith Williams's automation.

"Add community label" took an action on this PR • (03/11/25)

1 label was added to this PR based on Keith Williams's automation.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Mar 18, 2025

E2E results are ready!

},
}));

// A tiny helper to build a canned handler context with stubbed Prisma methods.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These comments are redundant since the code is self-explanatory

@anikdhabal anikdhabal merged commit 192238f into calcom:main Mar 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🐛 bug Something isn't working community Created by Linear-GitHub Sync embed area: embed, widget, react embed enterprise area: enterprise, audit log, organisation, SAML, SSO ready-for-e2e

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[CAL-5240] Embeds: UID cookie isn't accessible/created when in embed as it is third party context.

5 participants