-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
cookies: extend domain checks to non psl builds #2964
cookies: extend domain checks to non psl builds #2964
Conversation
It looks like this breaks test 8 in "torture mode" ... |
Test 8 seems to have failed and I think I know why, will fix. |
fa167e7
to
15df541
Compare
Pushed a fix which makes the test pass locally, fingers crossed that Travis agrees with me. |
Failed again, but not because of the patch this time.. |
15df541
to
769525f
Compare
769525f
to
38d0bfd
Compare
Ensure to perform the checks we have to enforce a sane domain in the cookie request. The check for non-PSL enabled builds is quite basic but it's better than nothing.
38d0bfd
to
a3bf73d
Compare
Force pushed a rebase to avoid the redness, even though it wasn't terribly related. @bagder do you still have doubts regarding the test? |
Red due to fuzzer build timing out |
I'm good! (apart from a bit concerned that we're closing in on the 50 minutes limit for the fuzzer tests more and more these days...) |
Thanks! I'll go ahead and merge this in the current feature window.
Yeah.. that's not good. Is it possible to get a larger instance to run the fuzzer on, by perhaps getting sponsorship for such a node? |
Pushed to master, thanks for review! |
This change broke using curl to hit a local unleash container in Kubernetes. We use the pod's name without any DNS. Is there anyway to turn this off besides compiling it ourself?
|
If you want to handle this as an issue, then please a file a new one. Commenting on an old closed PR will not get much attention by anyone.
No. Although I would rather suggest you instead change your setup to use more proper names so that HTTP cookies can be used the way they are documented to work rather than to lower the bars for curl... |
No, there are no options for this behaviour. The intention was to align non-libpsl builds with libpsl-enabled builds.
In your interpretation of the RFC and the follow-up draft, should this cookie have been allowed? Also, as @bagder mentioned upthread, please raise this on the mailing-list or as an issue. |
Ensure to perform the checks we have to enforce a sane domain in the cookie request. The check for non-PSL enabled builds is quite basic but it's better than nothing.
The preprocessor juggling around the PSL block which ends on an
else
may not be too everyones liking; I'm happy to refactor in that case.