Answers.Body: <p><strong>Check that your webserver serves correct cache headers when accessing the unsubscribe URL.</strong> It sounds like CloudFlare is caching the forms your CiviCRM install generates, and so a later anonymous visitor is seeing an expired form. </p>
  
  <p>While CloudFlare offers additional ways to customise what gets cached, using standard HTTP cache headers is your best bet because it works the same for CloudFlare and other caches your userbase might encounter (ISPs, corporate proxies, whatever).</p>
  
  <p>By default CiviCRM seems to set appropriate cache headers which tell CloudFlare not to cache forms, including unsubscribe forms.</p>
  
  <p>Let's see if CiviCRM sets cache headers suitably on an unsubscribe form. I searched my email for <code>civicrm/mailing/unsubscribe</code> to find an example URL.</p>
  
  <p>Fetch just the page headers using <code>curl</code> -</p>
  
  <pre><code>$ curl --head "http://example.org/civicrm/mailing/unsubscribe?reset=1&amp;jid=XXX&amp;qid=XXX&amp;h=XXXXXXXXXXXX"
  </code></pre>
  
  <p>And check that you see headers in the response that should prevent CloudFlare caching that page:</p>
  
  <pre><code>HTTP/1.1 200 OK
  Server: nginx/1.6.3
  Date: Tue, 13 Oct 2015 18:08:55 GMT
  Content-Type: text/html
  Connection: keep-alive
  Vary: Accept-Encoding
  Expires: Sun, 19 Nov 1978 05:00:00 GMT
  Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
  X-Micro-Cache: MISS
  </code></pre>
  
  <p>The interesting headers here are <strong>Expires</strong> (in the past) and <strong>Cache-Control</strong> (no-cache).</p>
  
  <p>You can compare those results to headers returned by your CiviCRM site for a similar request. Test using the URL that connects directly to your site, not using the CloudFlare URL, and confirm that appropriate cache headers will be set for requests to those URLs on your server.</p>
  
  <p>It <em>might</em> be that you have some other customisation or module which changes the cache headers for CiviCRM URLs, and that would then lead CloudFlare to believe that the forms should be cached.</p>
  
  <p>FWIW, we use CloudFlare on a few sites, and have no custom page rules in place; as far as I know it's worked with no special tweaks.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-14T16:52:20.930Z
Answers.Text: Ok thanks, I'll check that out. I'm steering more towards another module conflicting with the cache headers now as it appears to work on an IPAD but not any other desktop browser.
Answers.UserDisplayName: Rviner
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-20T12:11:11.320Z
Answers.Text: So the issue in the end was the auth cache version one module not writing session headers on page load so no session cookie existed. Upgrading to auth cache v2 fixes the issue.
Answers.UserDisplayName: Rviner
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-13T18:40:09.893Z
Answers.LastActivityDate: 2015-10-13T21:05:44.850Z
Answers.LastEditDate: 2015-10-13T21:05:44.850Z
Answers.UserDisplayName: Chris Burgess
Body: <p>Using Drupal 7.39 and Civicrm 4.6.9 -</p>
  
  <p>When submitting or cancelling the opt out and unsubscribe forms for anonymous users, I'm getting a 'could not find a valid session key message'. This does work however for authenticated users.</p>
  
  <p>My site is fully SSL running off cloudflare. I have checked the following:</p>
  
  <ol>
  <li>Resource urls are correct.</li>
  <li>Base url is correct.</li>
  <li>Cleared caches.</li>
  <li>0 user id in the database.</li>
  </ol>
  
  <p>Can you help?</p>
  
Tags: <email><session>
Title: Could not find a valid session key when submitting opt out and unsubscribe forms
ThreadText: # Could not find a valid session key when submitting opt out and unsubscribe forms
  
  (Asked by: username_0 on 2015-10-13)
  
  Using Drupal 7.39 and Civicrm 4.6.9 -
  
  When submitting or cancelling the opt out and unsubscribe forms for anonymous users, I'm getting a 'could not find a valid session key message'. This does work however for authenticated users.
  
  My site is fully SSL running off cloudflare. I have checked the following:
  
  1. Resource urls are correct.
  2. Base url is correct.
  3. Cleared caches.
  4. 0 user id in the database.
  
  Can you help?
  
  **Tags:** email, session
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-10-13. Score: 2
  
  **Check that your webserver serves correct cache headers when accessing the unsubscribe URL.** It sounds like CloudFlare is caching the forms your CiviCRM install generates, and so a later anonymous visitor is seeing an expired form.
  
  While CloudFlare offers additional ways to customise what gets cached, using standard HTTP cache headers is your best bet because it works the same for CloudFlare and other caches your userbase might encounter (ISPs, corporate proxies, whatever).
  
  By default CiviCRM seems to set appropriate cache headers which tell CloudFlare not to cache forms, including unsubscribe forms.
  
  Let's see if CiviCRM sets cache headers suitably on an unsubscribe form. I searched my email for `civicrm/mailing/unsubscribe` to find an example URL.
  
  Fetch just the page headers using `curl` -
  
  ```
  $ curl --head "http://example.org/civicrm/mailing/unsubscribe?reset=1&jid=XXX&qid=XXX&h=XXXXXXXXXXXX"
  
  ```
  
  And check that you see headers in the response that should prevent CloudFlare caching that page:
  
  ```
  HTTP/1.1 200 OK
  Server: nginx/1.6.3
  Date: Tue, 13 Oct 2015 18:08:55 GMT
  Content-Type: text/html
  Connection: keep-alive
  Vary: Accept-Encoding
  Expires: Sun, 19 Nov 1978 05:00:00 GMT
  Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
  X-Micro-Cache: MISS
  
  ```
  
  The interesting headers here are **Expires** (in the past) and **Cache-Control** (no-cache).
  
  You can compare those results to headers returned by your CiviCRM site for a similar request. Test using the URL that connects directly to your site, not using the CloudFlare URL, and confirm that appropriate cache headers will be set for requests to those URLs on your server.
  
  It *might* be that you have some other customisation or module which changes the cache headers for CiviCRM URLs, and that would then lead CloudFlare to believe that the forms should be cached.
  
  FWIW, we use CloudFlare on a few sites, and have no custom page rules in place; as far as I know it's worked with no special tweaks.
  
  > **Comments:**
  > **username_0**: Ok thanks, I'll check that out. I'm steering more towards another module conflicting with the cache headers now as it appears to work on an IPAD but not any other desktop browser.  
  > **username_0**: So the issue in the end was the auth cache version one module not writing session headers on page load so no session cookie existed. Upgrading to auth cache v2 fixes the issue.  
  
  ---
  
  