The logic for removing a trailing slash from WEBAPP_URL is duplicated in multiple places. Consider extracting this logic into a utility function to improve maintainability and reduce the risk of inconsistencies.

Same trailing-slash issue: if WEBAPP_URL already ends with '/', the resulting URL will contain '//' at the end.

WEBAPP_URL might already include a trailing slash, so concatenating it with /${normalizedCallbackUrl} can still produce a double-slash (e.g. https://cal.com//getting-started)—the exact bug this PR intends to solve.

Removing only a single trailing slash still allows malformed environment values like "https://example.com//" to produce a URL with a leftover slash, recreating the double-slash issue this patch attempts to solve.

The callbackUrl parameter is missing a leading slash, which may result in an incorrect relative path (e.g., /auth/login?callbackUrl=reschedule/abc instead of /auth/login?callbackUrl=/reschedule/abc). This could cause redirect issues if the login page expects an absolute path.

Removing the leading slash from callbackUrl may cause incorrect redirects if the receiving route expects an absolute path. Relative paths can break if the current URL is not the root, potentially leading to unexpected navigation or 404 errors. Consider using an absolute path (with a leading slash) for callbackUrl to ensure consistent behavior.

The logic for removing a trailing slash from WEBAPP_URL only removes a single trailing slash. If WEBAPP_URL ends with multiple slashes, this will still result in a double slash in the constructed URL. Consider using a more robust approach to remove all trailing slashes.

this one ??

@Devanshusharma2005 Yes, I’ve addressed that final issue sir. Please let me know if there’s anything else I should update. Appreciate your time!

If user.username is undefined or contains leading/trailing slashes, this could result in malformed URLs. Consider sanitizing user.username before constructing the URL.

callbackUrl can be an absolute URL (e.g. "https://example.com/foo"). Passing such a value to constructUrl will produce an invalid result like "https://cal.com/https://example.com/foo". The function should validate that callbackUrl is a relative path (or use the WHATWG URL constructor) before concatenation to avoid malformed redirects.

process.env.NEXT_PUBLIC_WEBAPP_URL may be undefined at runtime; passing undefined to constructUrl will throw when normalizeUrl tries to call .replace on it, causing a hard crash. Use the already-sanitised WEBAPP_URL constant (or provide a fallback) instead of relying on the non-null assertion.

Rule violated: Avoid Logging Sensitive Information

  Logs full URL path containing authentication token, violating rule 'Avoid Logging Sensitive Information'. Tokens should never be output to logs.

safeCallbackUrl returns the callbackUrl unchanged when it already starts with "http://" or "https://", allowing a user-supplied query parameter to redirect the browser to any external site. This introduces an open-redirect vulnerability that did not exist before (previous code always prefixed WEBAPP_URL).

If NEXT_PUBLIC_WEBAPP_URL is undefined at runtime, calling .replace on it will throw a TypeError, crashing the navigation handler. Previously the code interpolated the env var without calling a string method, which did not throw.

The callbackUrl value is interpolated directly into the query string without URL-encoding; if pathname contains query/hash characters this will break the final URL or enable open-redirect like manipulations. Use encodeURIComponent around the composed callback URL.

fullCallbackUrl is interpolated directly into the query-string without URL-encoding, so any “?” or “&” characters inside fullCallbackUrl will break the surrounding query string and/or leak unwanted parameters. Use encodeURIComponent when embedding it.

URL construction logic duplicates the standard URL constructor, which is already used in the WebAppURL class in the same file. The new function is also buggy.

usernameChangeCondition can be undefined, which would send the literal string "undefined" to the backend (…&action=undefined). This pollutes the query string and can break downstream handling expecting a valid action value.

Appending the raw searchString outside the encoded callbackUrl value causes any ‘&’ characters in searchString to be interpreted as top-level query delimiters, corrupting both the callbackUrl parameter and the original search parameters (e.g. “/auth/login?callbackUrl=%2Fhome?foo=bar&baz=qux” splits “baz” into a separate query param). Encode the full path + searchString together.

callbackUrl comes directly from the query string and may be an absolute URL (e.g. "https://evil.com"). The helper safeCallbackUrl does not enforce that the value is relative – when given an absolute URL it passes it straight through, which allows open-redirect attacks. Users clicking a crafted signup link could be redirected to an attacker-controlled domain after signup.