@@ -179,6 +179,8 @@ ${error.getFullMessage()}`,
179179 // proceed with triggering handshake.
180180 const isRedirectLoop = setHandshakeInfiniteRedirectionLoopHeaders ( handshakeHeaders ) ;
181181 if ( isRedirectLoop ) {
182+ const msg = `Clerk: Refreshing the session token resulted in an infinite redirect loop. This usually means that your Clerk instance keys do not match - make sure to copy the correct publishable and secret keys from the Clerk dashboard.` ;
183+ console . log ( msg ) ;
182184 return signedOut ( authenticateContext , reason , message ) ;
183185 }
184186 return handshake ( authenticateContext , reason , message , handshakeHeaders ) ;
@@ -210,7 +212,7 @@ ${error.getFullMessage()}`,
210212 }
211213
212214 const newCounterValue = authenticateContext . handshakeRedirectLoopCounter + 1 ;
213- const cookieName = constants . Cookies . InfiniteRedirectionLoopCookie ;
215+ const cookieName = constants . Cookies . RedirectCount ;
214216 headers . append ( 'Set-Cookie' , `${ cookieName } =${ newCounterValue } ; SameSite=Lax; HttpOnly; Max-Age=3` ) ;
215217 return false ;
216218 }
@@ -229,30 +231,6 @@ ${error.getFullMessage()}`,
229231 throw new Error ( `Clerk: Handshake token verification failed: ${ error . getFullMessage ( ) } .` ) ;
230232 }
231233
232- function handleHandshakeTokenVerificationErrorInProduction ( error : TokenVerificationError ) {
233- // In production, the handshake token is being transferred as a cookie, so there is a possibility of collision
234- // with a handshake token of another app running on the same etld+1 domain.
235- // For example, if one app is running on sub1.clerk.com and another on sub2.clerk.com, the handshake token
236- // cookie for both apps will be set on etld+1 (clerk.com) so there's a possibility that one app will accidentally
237- // use the handshake token of a different app during the handshake flow.
238- // In this scenario, verification will fail with TokenInvalidSignature. In contrast to the development case,
239- // we need to allow the flow to continue so the app eventually retries another handshake with the correct token.
240- // We need to make sure, however, that we don't allow the flow to continue indefinitely, so we throw an error after X
241- // retries to avoid an infinite loop. An infinite loop can happen if the customer switched Clerk keys for their prod app.
242- if (
243- error . reason === TokenVerificationErrorReason . TokenInvalidSignature ||
244- error . reason === TokenVerificationErrorReason . InvalidSecretKey ||
245- error . reason === TokenVerificationErrorReason . JWKKidMismatch ||
246- error . reason === TokenVerificationErrorReason . JWKFailedToResolve
247- ) {
248- // Let the request go through and eventually retry another handshake,
249- // only if needed - a handshake will be thrown if another rule matches
250- return ;
251- }
252- const msg = `Clerk: Handshake token verification failed with "${ error . getFullMessage ( ) } "` ;
253- return signedOut ( authenticateContext , AuthErrorReason . UnexpectedError , msg ) ;
254- }
255-
256234 async function authenticateRequestWithTokenInCookie ( ) {
257235 const hasActiveClient = authenticateContext . clientUat ;
258236 const hasSessionToken = ! ! authenticateContext . sessionTokenInCookie ;
@@ -270,19 +248,22 @@ ${error.getFullMessage()}`,
270248 try {
271249 return await resolveHandshake ( ) ;
272250 } catch ( error ) {
251+ // In production, the handshake token is being transferred as a cookie, so there is a possibility of collision
252+ // with a handshake token of another app running on the same etld+1 domain.
253+ // For example, if one app is running on sub1.clerk.com and another on sub2.clerk.com, the handshake token
254+ // cookie for both apps will be set on etld+1 (clerk.com) so there's a possibility that one app will accidentally
255+ // use the handshake token of a different app during the handshake flow.
256+ // In this scenario, verification will fail with TokenInvalidSignature. In contrast to the development case,
257+ // we need to allow the flow to continue so the app eventually retries another handshake with the correct token.
258+ // We need to make sure, however, that we don't allow the flow to continue indefinitely, so we throw an error after X
259+ // retries to avoid an infinite loop. An infinite loop can happen if the customer switched Clerk keys for their prod app.
260+
261+ // Check the handleHandshakeTokenVerificationErrorInDevelopment function for the development case.
273262 if ( error instanceof TokenVerificationError && authenticateContext . instanceType === 'development' ) {
274263 handleHandshakeTokenVerificationErrorInDevelopment ( error ) ;
275264 }
276-
277- if ( error instanceof TokenVerificationError && authenticateContext . instanceType === 'production' ) {
278- const terminateEarly = handleHandshakeTokenVerificationErrorInProduction ( error ) ;
279- if ( terminateEarly ) {
280- return terminateEarly ;
281- }
282- }
283265 }
284266 }
285-
286267 /**
287268 * Otherwise, check for "known unknown" auth states that we can resolve with a handshake.
288269 */
0 commit comments