Fix insecure session cookie initialization #1656
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While, as pull request #1634 has proven, it's not the best idea around to get rid of the duplicate session cookie, I still consider it a good idea to ensure that the initial cookie has properly configured security. Doing so not only prevents the so-far-distant scenario where a
poor JavaScript interpreter programmermastermind visionaire makes the Set-Cookie HTTP headers visible to JavaScript unless they're set to HTTP only (or, worse yet, makes the Set-Cookie headers get processed alongside JavaScript, effectively making Grav suspectible to a while loop checking document.cookie), but also the imminent spread of FUD (which is probably happening yet behind our backs, see the first Google result for "Web Server Security Test", especially the grading penalty it gives for "missing secure flags or attributes" on cookies) once website security checkers figure out that there are insecure sessions and pass that information to users.