API call using custom action and Http only cookie
Hi ! I 've built a custom action to handle an API call that streams responses in a format the built -in API system doesn 't parse correctly . The action fetches data , processes the streaming response , and passes it to a component —everything works perfectly . However , I 've run into an issue : I can 't use HTTP -only cookies for the authorization token with this custom action . Is there a known workaround for this , or an alternative approach I should consider ? Thanks in advance for any guidance ! None of the settings under the Advanced tab help ? (parse as ) Custom actions (client -side JS ) cannot access httpOnly cookies Hi , is JSON lines from a n8n agent . Json stream work somehow , but generated error some times ( "line x couldnt chunk /parse or something like that ) . It worked 95 % of the time . . . but when it generate the error it produce other errors in other workflows . With custom action work perfectly and I have a lot of more control of how the parsing and streaming occurs . To address it right now , I 'd look at parsing /returning the full JSON for now instead of streaming it until you iron out what 's causing certain chunks to error out From my understanding , even though you cannot access the cookie content itself using javascript , you can instruct the browser to send the http -only -cookies with the fetch call . The only problem is that you cannot choose which cookie to send . But it seem that with cookie attributes like path /domain this could be potentially solve if the target cookie is for a specific domain . Im experimenting with that now . . . My goal is to find a secure way to make client -side API calls to a webhook using a custom action . My current strategy is to , after the user 's first message , generate a unique session JWT token on the server with Supabase that includes an expiration date and signed payload with specific attributes for the target endpoint . This token is saved in an HTTP -only cookie , sent with fetch calls using credentials : 'include ' , and validated on the server before processing the request . This protects against XSS attacks while enabling secure client -side API calls using custom action (and with all its flexibility and customization ) The browser will send the cookies that fit the request URL , you 'd have to verify things on the server though as you wouldn 't be building an Auth Bearer header in that case 👍1Yes , not being able to build an Auth Bearer header is a limitation (and the one that inspire this thread ) . It seems that In practice you can only call endpoints where you can configure how the cookie is read and validated . But it does open some interesting possibilities be able to do it through a custom action .
.jpeg/public)