@@ -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 }  ) ; 
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