4 ms·
Thanks. I guess if you're using cloudfront then it's best to use a seperate sub-domain and link to them directly because you don't want to redirect it through t
by superasn 9y ago
Thanks. I guess if you're using cloudfront then it's best to use a seperate sub-domain and link to them directly because you don't want to redirect it through the Api gateway/lambda as it will add to the load time and exhaust your quota.
You're right about JWT. It does seem like a better solution for handling sessions and I'm sure somebody must have already written the wrapper for it, so it's just a matter of integrating. Though with JWT is there a limit on the session data length? Because right now it can be anything. If iirc with Jwt the cookie contains the entire session data, right?
- Willson50 9y agoI found this JWT implementation which claims to replace $_SESSION https://github.com/byjg/jwt-session https://github.com/byjg/jwt-session Yea JWT maxes out around 8KB vs DynamoDB's 400KB Also, the CloudFront storage problem exists with many other serverless frameworks like Zappa so I don't blame you for not solving it yet haha.
- guitarbill 9y ago> This implementation save the JWT into a client cookie. Because of this do not store in the JWT Token sensible data like passwords. JWT is designed for authentication claims, and not to completely replace $_SESSION data, although technically you can stuff as much as you want into the payload. The wording makes me uneasy about the implementation - but decent advice otherwise. (Also note that getting JWT implementations/crypto right is somewhat tricky, obvs. Caveat emptor) On a quick note, storing big blobs of data in DynamoDB is asking for trouble, and AWS actually recommend S3 for this [0]. Best to not find this out the hard way (i.e. huge bill). [0] https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForItems.html#GuidelinesForItems.StoringInS3 https://docs.aws.amazon.com/amazondynamodb/latest/developerg...