I'm attempting to forward cookies from my auth route to the query. I followed the instructions at Custom API authentication but it doesn't seem to be forwarding the cookie. I am not able to determine if it is an issue on my end or Retool's, and I'm not sure how to go about finding out why it is missing.
I set FORWARDABLE_SAME_DOMAIN_COOKIES_ALLOWLIST to the cookie I want to forward, but also checked "Forward all cookies" for good measure.
Also, when I test the auth workflow, the page refreshes, so I'm not able to retrieve the scopes that show momentarily under the test button.
Here it is in 3 screenshots with possibly sensitive info redacted.
The query string in custom auth flow got cut off, but basically it is: ?callback=urlAbove&nonce={{ csrfNonce }}, with callback being the URL specified above.
Also, I just tried changing the auth cookie that .NET 6 generates to SameSite=None, since that just helped with my frontend and Apollo Client, but that didn't make a difference for Retool.
Just to double check, how are you trying to use the forwarded cookie in your query?
Would you be able to use your cookie in your Header section of your resource field and share what you see in http2.headers when you click Test auth workflow?
I'm curious to see the structure and not the actual values to make sure that the set-cookie header is being returned as expected. Hopefully that will help us see how to reference the cookie. Then, with 'Forward All Cookies' set, you shouldn't need to define a variable but should just be able to reference the cookie with COOKIE_cookie_name.
For example, if your cookie name is X-HS-IAuth then your header could look like this
It is tricky to get the requested info because I'm using "Redirect to SSO", not "API Request", as in your screenshot. When clicking "Test auth workflow" before I can see anything in the scopes this causes the screen to refresh, and then after it refreshes the scopes just show as an empty object {}.
Interestingly, in my logs, I can see that the Retool "Test auth workflow" action is hitting my login process and succeeding. However, it seems like Retool is not correctly processing the resulting callback to set the cookie. I tried passing it up in the X-Auth Header as you suggested and it still acts the same.
[Edit] Here is the log that I put in my login function (with our real domain replaced with retool.ourcompany.com):
User Evan Kaiser logged in and is being redirected back to https://retool.ourcompany.com/oauth/user/redirectCallback?nonce=6b903bd8-ad3b-4332-9581-f78797ccd6cd
[Edit2] The cookie that has the login credentials is called .AspNetCore.Cookies, so this is the full header I set (on both the resource itself and the Login Test URL):
Quick check! Can you confirm that the cookies are actually being set in the browser? We should be able to see some _rmc_ prefixed cookies in the dev tools > application > cookies
It looks like it is not being set correctly. Interestingly, it is setting 2 other cookies from our site. I looked at the difference in settings with the ones that are being set and the one I need and it looks like the missing one has HttpOnly == true.
I don't know what you mean by that. The cookie is not being set by the Retool code. Please look at the images again. The first one shows that our app is setting the cookie when going directly to our login route, but Retool is only setting the 2 out of 3 when it goes to the login route through testing the custom auth flow.
[Edit] I finally realize by "add that to your missing cookie" you meant remove the HttpOnly flag. From what I understand, that can lead to XSS attacks, but I'll try it for educational purposes at least.
I tried this change and cleared the cookies and re-logged in again. Now it seems like none of the cookies are being set. Maybe I just don't understand how your Redirect to SSO is supposed to work, but this really is getting frustrating. It would be great if there was more documentation on the different custom auth steps, since the only documentation I could find on the whole process only uses API Request: Custom API authentication
I thought of a workaround to this issue that would involve a 2nd step of authenticating with an API Request, but I really need to know how to parse the response from the Redirect to SSO.
Unfortunately, I have no idea what is in these 2 variables that are a response from that step, and as I stated previously, it refreshes so the output is not present in the resources tool. I think if I could somehow output these 2 variables to see what is in them, I might be able to use the workaround. Is there any documentation about the structure of these?
@victoria - i am running into same exact issue. any suggestions on how we parse the redirect1.urlparams and redirect1.hashparams or how do we even see whats in there to make any meaningful use of them ?
Great question. If you are looking to use JWTs passed back from your SSO provider, for example, you can set up custom auth. You can then refer to these tokens by keying into the response from your custom auth using {{redirect1.urlparams}} or {{redirect1.hashparams}}.
Do you have any examples of how your auth response looks, from postman or another similar service?
