You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lambda-api is a great package and has been really helpful in our one single backend lambda architecture 🚀
Today, I faced a really hard to debug issue and I though passing the information here if it helps anyone else. I was running our app with SAM CLI and everything worked like a charm, but when I deployed to AWS lambda, it worked in really weird way.
The problem was that I had somewhat the following structure:
constcookieOptions: CookieOptions={sameSite: 'Lax',secure: true,httpOnly: true,}// And pseudo authenticationapi.post('/login',async(req,res)=>{// Do login stuffres.setCookie('authcookie',sessionId,cookieOpts).json({message: "Authenticated"})})api.post('/logout',async(req,res)=>{// Do logout stuffres.clearCookie('authcookie',cookieOpts).json({message: "Logged out"})})
It worked locally like a charm. But when it was deployed to AWS Lambda, it worked like this:
Login - OK you get a cookie
Logout - OK cookie gets evicted
Login - FAILS and no cookie is set
After some time, it starts to work again, for once 😂
After some weird debugging I found out that the third call gets correct cookie, but with expiration set to -1, so the browser thinks that yes, unset the cookie.
Obvious reason for this is that response.clearCookie call mutates the given opts instance:
After the first response.clearCookie call my opts instance was mutated to contain expiration: -1 field and calls to response.setCookie after that naturally included the expiration.
The reason why it works after some time in AWS lambda is that runtime spins up a new sandbox and then it works again, for once 😄, because opts instance is not mutated and no one has logged out. Locally SAM CLI fires a whole new sandbox for each request and thus it worked locally with no issues.
You can easily work around this for example by wrapping opts in function:
It surely took me some time to figure out what is going on 😄 I don't think this is mentioned in documentation. I think I can work out a PR for this if this is something that should be fixed - in code or with documentation.
The text was updated successfully, but these errors were encountered:
Hi!
Lambda-api is a great package and has been really helpful in our one single backend lambda architecture 🚀
Today, I faced a really hard to debug issue and I though passing the information here if it helps anyone else. I was running our app with SAM CLI and everything worked like a charm, but when I deployed to AWS lambda, it worked in really weird way.
The problem was that I had somewhat the following structure:
It worked locally like a charm. But when it was deployed to AWS Lambda, it worked like this:
After some weird debugging I found out that the third call gets correct cookie, but with expiration set to -1, so the browser thinks that yes, unset the cookie.
Obvious reason for this is that
response.clearCookie
call mutates the given opts instance:lambda-api/lib/response.js
Lines 221 to 224 in 0b753d8
After the first
response.clearCookie
call my opts instance was mutated to containexpiration: -1
field and calls toresponse.setCookie
after that naturally included the expiration.The reason why it works after some time in AWS lambda is that runtime spins up a new sandbox and then it works again, for once 😄, because opts instance is not mutated and no one has logged out. Locally SAM CLI fires a whole new sandbox for each request and thus it worked locally with no issues.
You can easily work around this for example by wrapping opts in function:
It surely took me some time to figure out what is going on 😄 I don't think this is mentioned in documentation. I think I can work out a PR for this if this is something that should be fixed - in code or with documentation.
The text was updated successfully, but these errors were encountered: