# Inconsistent Signed-In State behind fastly

**URL:** <https://meta.discourse.org/t/inconsistent-signed-in-state-behind-fastly/136371>\
**Category:** Self-hosting\
**Tags:** cdn\
**Created:** [December 18, 2019, 3:05am UTC](https://meta.discourse.org/t/inconsistent-signed-in-state-behind-fastly/136371 "2019-12-18T03:05:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![JackCA](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@JackCA](https://meta.discourse.org/u/JackCA)\
**Post date:** [December 18, 2019, 3:05am UTC](https://meta.discourse.org/t/inconsistent-signed-in-state-behind-fastly/136371/1 "2019-12-18T03:05:41Z")

</div>

I’m having a bit of a strange issue but there are a lot of factors at play.

**Issue:**

when I am logged in and I navigate directly to my forum’s home page, it appears as if I’m not logged in, in the UI e.g. the navbar has sign-up/sign-in links instead of the user avatar.

Navigating directly to a specific post, will result in the correct signed-in state and subsequent pushstate transitions work, including going to the home page. However, a reload on the homepage will result in it appearing logged out (as above).

**Background:**

I am using discourse fully behind Fastly, except for the polling functionality which is communicating directly with my GCP Compute Instance.

My guess is that this has something to do with the caching layer, but I have been pretty careful to read through the discussions on this forum. I do not have Fastly’s automatic GZIP compression turned on.

The [forum is here](https://community.midi.city) and [here’s a video of the above](https://streamable.com/qg10k).

---

<div class="post-metadata">

**Author:** ![JackCA](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@JackCA](https://meta.discourse.org/u/JackCA)\
**Post date:** [December 18, 2019, 5:43am UTC](https://meta.discourse.org/t/inconsistent-signed-in-state-behind-fastly/136371/2 "2019-12-18T05:43:50Z")

</div>

Upon further investigation, I think the issue may be related to when the Cache-Control response header is `no-cache, no-store` in combination with [Fastly not respecting those values](https://docs.fastly.com/en/guides/cache-control-tutorial#do-not-cache).

My Fastly CDN was marking what looked like a noscript version of the home page for a web crawler as HIT’s because it must have crawled with the `no-cache, no-store` value.

Fastly suggests adding an `Expires: 0` in situations like this.

[I’ve implemented this](https://support.fastly.com/hc/en-us/community/posts/360040169571-Caching-happens-when-no-cache-or-no-store-requested) as suggested by the fastly docs in the meantime.