search

apex / up

Deploy infinitely scalable serverless apps, apis, and sites in seconds to AWS.
https://up.docs.apex.sh
MIT License
8.8k stars 378 forks source link

Set-Cookie Automation With Custom Domains #323

Closed larron closed 7 years ago

larron commented 7 years ago

To currently use cookies in lambda with a custom domain one must enter into the AWS Console and follow something along the lines of: https://aws.amazon.com/blogs/compute/simply-serverless-using-aws-lambda-to-expose-custom-cookies-with-api-gateway/

This document was a bit outdated but I was able to ultimately get cookies working by following it after a day or so of fighting with koa-session. I did extensive testing with up and I believe what it comes down to is the use of a custom domain (cloudfront) with API Gateway.

I am recently aware of the header config for up however after reading the documents I believe it is a completely different feature?

Cookie automation within lambda would be an excellent feature, it certainly was a gotcha for me.

agurtovoy commented 7 years ago

Ditto.

tj commented 7 years ago

Hmm thanks for pointing this out. I haven't used cookies in a while, but this seems related to the WWW-Authorization header issue, I'm not sure why API Gateway tampers with that stuff at all..

Just to clarify, you're having issues reading the cookies or using set-cookie? Or both? I'll try and replicate in my examples repo tomorrow.

larron commented 7 years ago

Yah! It was very annoying. I almost gave up and then stumbled upon that article. I thought the concept of up was amazing but my goal was to discover if lambda was actually even feasible for a full blown app of any sorts.

Anyhow if you need my help to re-create this issue feel free to ping me. I basically used a combination of koa, koa-session and koa passport with a google strategy. When googles oauth2 continued to fail (only on lambda) one thing led to another and I finally arrived at the above. Testing again this morning things seem ok 👌 With that being said I look forward to up's progression. Keep up the great work! (Pun intended) LOL

larron commented 7 years ago

Also to clarify Set-Cookie was ultimately what fixed it. So I am assuming setting was the problem. (Not sure if reading also was broken) I added a koa with cookies to the examples repo locally and deployed it and it worked which led me to discover that it was cloudfronts doing with the custom domain / API gateway config.

tj commented 7 years ago

hmmm I wasn't able to reproduce any issue with https://github.com/apex/up-examples/commit/32de2f3906a79353468a441459462c115aa462f4, closing for now but feel free to re-open if anyone hits an issue

larron commented 7 years ago

@tj I'll see if I can break down what I've got and reproduce in the example repo! Thanks TJ

tamagokun commented 7 years ago

Just ran into this problem this morning. Using koa koa-sessions and koa-passport with Google oauth. Is this still a problem related to custom domains? Also, how can that article be used to produce a workaround? It seems like you can't manage the integration response for a proxy.

tj commented 7 years ago

@tamagokun API Gateway (or CloudFront?) has issues with multiple set-cookie header fields in the response, I wonder if that's why there's an issue? I think it's a problem with API Gateway if I recall, and not the custom domain side of things.

larron commented 7 years ago

@tamagokun Exact same setup I was playing with, koa, koa-session, google and all... I thought I had it working at one point and then it stopped and started and stopped... It was so inconsistent I eventually gave up on lambda after a week of disappointment :(

tamagokun commented 7 years ago

@tj I have a hunch it's an issue with session storage, and not cookie headers. Currently i'm having an issue reading a cookie from a subsequent request. Cookie header is being passed, but the request is coming back as unauthorized. Hard to track down since the usual behavior of this problem is an infinite redirect loop.

tamagokun commented 7 years ago

UPDATE: Appears to be completely session storage related, which makes perfect sense.

Default session stores just use memory, but since the lambda process is constantly restarting, sessions get lost, and invalidated, however using this oauth mechanism it ends up falling into a redirect loop. I think in most scenarios, you'd just keep getting thrown back to the login screen (for auth stuff).

I re-deployed using a redis cluster as the session store, and it worked great!

@larron you should try using an external session store, see if that solves it.

larron commented 7 years ago

Tried that too, it didn't seem to stay consistent. You can actually stop using the session store for redis and just leave the redis connection and it'll appear to work. I think something about the redis connection kept the lambda open long enough to work with the google connect and then... it stopped working again out of the blue. Give it a bit and test it again. I literally woke up the next morning and it was broke for no reason.

tamagokun commented 7 years ago

interesting. I'll keep an eye on it!

tj commented 7 years ago

Hmm sounds like possibly a poorly written Redis driver. I use Postgres in Lambda for example, and the connections come and go as functions are invoked, but it just re-connects and performs the query.

Not directly related but JWT is a great alternative for a session store, that's my go-to these days, stateless is nice (aside from revoking).

larron commented 7 years ago

Interesting! @tamagokun Please keep us updated :) Maybe I can give this another go as well. @tj I love the idea of JWT, do you have any recommendations on launching something that's open source like gluuserver or hydra that would allow you to use JWT out of the box?

stephenmathieson commented 7 years ago

I've used both of these in the past when dealing with JWTs:

tamagokun commented 7 years ago

@larron still working really well today, keep trying to break it, but still working well. Like @tj said, it sounds more like a bad redis lib? Not sure. I am using koa-redis and compose.io for my redis cluster.

JWT sounds even better still, been meaning to give it a go.

tamagokun commented 7 years ago

Following the same "flow", using https://github.com/longlh/passport-google-oauth-jwt and https://github.com/koajs/jwt could probably work well.

larron commented 7 years ago

Thanks guys! I will be certain to look back into this with a renewed hope :)

tamagokun commented 7 years ago

I made a little module to handle this for me: https://github.com/ripeworks/koa-google-jwt

Since it uses jwt and not sessions, setting up passport and sessions, etc seemed like overkill. This is pretty simple.