10000 Varnish cookbook session cookie handling by dbu · Pull Request #4628 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

Varnish cookbook session cookie handling #4628

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Jan 30, 2015
Merged

Varnish cookbook session cookie handling #4628

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c88ad32
explain how to work with cookies and sessions when caching
dbu Dec 11, 2014
7a4dafc
remove part about vary on cookie
dbu Dec 31, 2014
b294b24
cleanup from feedback
dbu Jan 1, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
cleanup from feedback 
* link user context to relevant section of the doc
* better explain what we achieve with cleaning the cookies
  • Loading branch information
@dbu
dbu committed Jan 18, 2015
commit b294b245a1dc57fbd80cd2f5e146c0a98e8dd746
14 changes: 9 additions & 5 deletions cookbook/cache/varnish.rst
View file
Open in desktop
8000
Original file line number Diff line number Diff line change
Expand Up @@ -74,20 +74,22 @@ prevent clients from bypassing the cache. In practice, you will need sessions
at least for some parts of the site, e.g. when using forms with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may we could go a step in this direction?

even if you drop the Cookie Header using Varnish, on the client side you can access them using JavaScript. For example you could extract the username from a cookie and replace the markup to display a custom welcome message.
In practice some parts of the site aren't cacheable for all users and sometimes it's not possible to solve this issues using JavaScript. For example consider you have a Form with a CSRF Protection. In this situation every user needs to get a unique token for the CSRF Protection. Here you can decide not the cache the whole Page. An alternative would be not to cache an ESI Request that is delivering the part of the Form that is responsible for the CSRF protection or decide to cache based on a user specific cookie. Using the Vary Header you can make sure that Varnish is caching based on another Header. Using Vary in combination with the Cookie Header allows you to fill up the Varnish cache with custom elements for every different cookie value. if the cookie value depends on the user, you are able to cache custom pages in varnish. Often there are a bunch of strategies with different advantages and disadvantages. Choosing the right caching strategy depdends on you use case, your Infrastructure and your Team.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dbu may go could use some parts of https://github.com/symfony/symfony-docs/pull/4628/files#r22298163 ? i just want to make sure that the reader get the idea that there a a bunch of caching strategies. filling up the varnish with user specific data is probably the worst one :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think this cookbook should talk about general strategies to sort out cacheable from user content. there is the book chapter on caching that explains ESI. the topic of moving small things to javascript cookies is not specific to varnish but to caching in general and should rather go into #4661 or next to that. there is also #4141 which would cover the CSRF part of the topic.

ideally, both #4661 and #4141 would be wrapped up and merged, then this section would simply summarize and link information. if you want to add something to #4661 or next to it about moving information into javascript cookies that can be ignored by varnish, that would be useful information too.

#4141 is rather old however, so maybe i should just shorten this section and remove things that are too complicated / dangerous here.

:ref:`CSRF Protection <forms-csrf>`. In this situation, make sure to only
start a session when actually needed, and clear the session when it is no
longer needed.
longer needed. Alternatively, you can look into :doc:`../cache/form_csrf_caching`.

.. todo link "CSRF Protection" to https://github.com/symfony/symfony-docs/pull/4141
.. todo link "only start a session when actually needed" to cookbook/session/avoid_session_start once https://github.com/symfony/symfony-docs/pull/4661 is merged
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of todos got left here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. those PRs are not merged yet so i can't do that now. if we can wrap up the others really quick, i am happy to wait and update in a few days. otherwise i propose to merge already and hope that those PRs happen - or try to add the change in the respective PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eliminated one of the TODOs . #4661 is still not merged, so i can't link to that. can we wrap those up?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think #4661 is kind of blocked because of the difficulty of the topic - you have 1 open question and 1 todo on that issue that I can't answer without some time to look into things.

As an aside, for me, this smells like a bug or missing feature in Symfony. I think the PR symfony/symfony#6388 or issue symfony/symfony#6036 need to be finally pushed along - the functionality just isn't right. Of course, that's an even bigger task.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay. can we get this PR merged then? looks like the session start issue is a potentially long story.

or do you not want todos in the doc code? should we create a new issue to remind us that when #4661 is merged we add a reference in this section of the doc.


Cookies created in Javascript and used only in the frontend, e.g. when using
Google analytics are nonetheless sent to the server. These cookies are not
relevant for the backend and should not affect the caching decision. Configure
your Varnish cache to `clean the cookies header`_. Unless you changed the
default configuration of PHP, your session cookie has the name PHPSESSID:
your Varnish cache to `clean the cookies header`_. You want to keep the
session cookie, if there is one, and get rid of all other cookies so that pages
are cached if there is no active session. Unless you changed the default
configuration of PHP, your session cookie has the name PHPSESSID:

.. code-block:: varnish4

sub vcl_recv {
// Remove all cookies except the session ID.
if (req.http.Cookie) {
set req.http.Cookie = ";" + req.http.Cookie;
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
Expand All @@ -96,6 +98,7 @@ default configuration of PHP, your session cookie has the name PHPSESSID:
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");

if (req.http.Cookie == "") {
// If there are no more cookies, remove the header to get page cached.
remove req.http.Cookie;
}
}
Expand All @@ -106,7 +109,7 @@ default configuration of PHP, your session cookie has the name PHPSESSID:
If content is not different for every user, but depends on the roles of a
user, a solution is to separate the cache per group. This pattern is
implemented and explained by the FOSHttpCacheBundle_ under the name
*User Context*.
`User Context`_.

Ensure Consistent Caching Behaviour
-----------------------------------
Expand Down Expand Up @@ -221,3 +224,4 @@ proxy before it has expired, it adds complexity to your caching setup.
.. _`Surrogate-Capability Header`: http://www.w3.org/TR/edge-arch
.. _`cache invalidation`: http://tools.ietf.org/html/rfc2616#section-13.10
.. _`FOSHttpCacheBundle`: http://foshttpcachebundle.readthedocs.org/
.. _`User Context`: http://foshttpcachebundle.readthedocs.org/en/latest/features/user-context.html
0