Hi! I've got another question 😅 I am using the descope react-sdk, and I am managing my refresh token in my cookies. my question is during local development how does this work without getting CORS issues? the cname I set up does not work because I am using localhost. do y'all have any tips?

Could you try and handle the refresh token using localStorage rather than cookies, just to see if that resolves the issue?

oh it probably would but i would be nervous of drift between local dev and production

Obviously this is not a fix, but I'm curious to see if that resolves the CORS issue, since you don't have the

httpOnly

restriction

ahhh I see

Yes ok I think it's due to the fact that the cookies are

strict

I forgot to mention i'm using Oauth. google social login. when I click sign in with google and I have a baseURL

<DescopeAuthProvider
        projectId={import.meta.env.VITE_DESCOPE_PROJECT_ID}
        baseUrl="<http://auth.app.dopt.com>"
      >

it doesn't work because of cors. So I'm not even at the point of getting a refresh token back

a way to separate it , is create 2 projects 1 for PROD 1 for DEV (localhost) in PROD, project use cookies with your domain in DEV project, use localhost in the cookie (or keep empty) OR don't use cookies

okay so i've got it set up like that! now when you say

use localhost in the cookie (or keep empty) OR

do you mean in i should put localhost as my custom domain?

Token response method

or put localhost in approved domain or both?

so both options should work, either you choose

Manage in response body

, in that case it will store refresh and session tokens in local storage

I would ike to have it as mange in cookies in dev as well

Few options: 1. Tunnel, there are services like Ngrok/Cloudflare for that 2. Setup a staging env, a replica of your prod, with diff domain, that is usually a general deployment best practice Both will require another CNAME configured of course On a side note, we planning to work soon on a feature to better streamline this part, have easy way to manage several environments

oh bummer. hmm what are the consequences of using two different mechanisms for storing refresh tokens. one in prod and one in dev? you can't use

sessionTokenViaCookie

in the DescopeAuthProvider? but other than that is it the same? are the access patterns the same in both methods in the react-sdk? what about the web-js-sdk? Edit: what about automatic token refresh? and sending the token to the backend for session validation? I would really not like to have different logic for local dev and prod

sessionTokenViaCookie

will force send the session token as a cookie but not the refresh token. The refresh token is handled in the console settings

nice that sounds good