serverless-java-container icon indicating copy to clipboard operation
serverless-java-container copied to clipboard

Problems Reading Cookies

Open ryber opened this issue 6 years ago • 4 comments

  • Framework version: 1.3.2
  • Implementations: Spark

Scenario

Lambda is fronted by API Gateway which is in turn fronted by cloudfront which is the host of the public vanity URL.

Code is the lambda is looking for a cookie but cannot get get. I assume that this is because it's not getting x-forwarded data? In a similar situation with a ELB running Spring/tomcat we had a similar problem and needed to add the following properties to Spring:

server.tomcat.remote-ip-header=x-forwarded-for server.tomcat.protocol-header=x-forwarded-proto

I assume there is something like this for Spark? I don't see anything in their documentation?

Expected behavior

Can read cookies on the vanity domain

Actual behavior

no cookies :(

Steps to reproduce

Create the above scenario

Thank You!

ryber avatar Aug 01 '19 20:08 ryber

Hi @ryber, apologies for the delay. Any chance you can share the snippet of code you are using to read the cookies in Spark?

Technically the Cookies header should be forwarded just fine through CloudFront and API Gateway. To confirm, you are using a proxy integration in the API Gateway config right?

sapessi avatar Aug 11 '19 15:08 sapessi

I've been trying to replicate this in the unit tests but I can read cookies just fine. I wonder if this is related to how the cookie is set rather than how it is read. When you set the cookie, is it associated with the custom domain name? Do you set the domain name manually on the cookie?

sapessi avatar Sep 27 '19 05:09 sapessi

OMG, I'm really sorry, we found that this was a problem with the cookies not being forwarded on from the proxy or load balancer we have in front of it (we have changed it several times). So it was not a problem with the actual lambda part although it was a bear to diagnose exactly where it was. You can close this. Again sorry for not closing this earlier, I thought I had. :(

ryber avatar Sep 28 '19 13:09 ryber

Thanks for the update @ryber. As you said, it was a bear to debug. I'll keep this issue open and re-purpose it to add a debug parameter in the configuration that logs the full request and response as it's processed for the next release.

sapessi avatar Sep 28 '19 15:09 sapessi