-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bundle #1
Comments
as for submodules, they've given me enough grief already, and keygrip is not a hard dependency; it's optional only if you want to sign cookies. |
I'd say in our modern world unsigned cookies are evil ;) I read the deprecation note and didn't get what is the killer improvement over cookie-node? Couldn't you elaborate on this? TIA |
vladimir, good point. i've added a |
Plain text signed cookies, even though can't be tampered, seem a bit more disclosing than I'd expect. Just reading them at sniffer level already provides valuable info. Wrong? So the hardened (in fact, vanilla) solution (using secure, httponly, and Still, great repo, thanks! |
i think that if you're putting valuable information in a cookie, you're doing it wrong, and no library should encourage that. so i don't think it's wise to try and over engineer something in this case. do you think the |
I do put user id in cookie, that's requirement for a project I do. But they don't want it be "visible" in plain. I know that's quirky but so things are. NVM No, defaults are ok to me. The only inconvenience so far is that keygrip |
that makes sense. i've changed
for some reason the GitHub interface isn't reflecting this latest push yet, but it should be there soon. |
Couldn't you help those who don't use npm? keygrip as submodule, plus Makefile to perform installation, e.g. to generate defaultKeys?
TIA,
--Vladimir++
The text was updated successfully, but these errors were encountered: