* Adjusting ArticlePolicy for admin only posting
The goal of this commit is actually two fold:
1) To add documentation regarding my current emerging understanding of
our caching implementation as it relates to our authorization and
authentication.
2) Flippiing "on" the feature's core authorization check.
Buried within this is the desired normalization of the authorization
between the `ArticlePolicy`'s `#create?`, `#preview?`, `#new?`.
My testing plan for this is to ask for SRE to spin-up a canary, then
test. What does that look like? I'm uncertain because this is nudge
closer towards our edge-caching strategy. Which makes robust testing
more difficult.
Closes forem/forem#16483
Related to #16529, #16571, #16536, #16529
Informs #16490, #16606
* Update spec/requests/editor_spec.rb
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Let dev/test blow up if current_user is used erroneously
* Fix logic
* Fix click-to-edit permissions
* Change test to check for new behavior
* linting
* Edit tests
* Change test
* Clean up implementation
* Update comment
* Fix instance vars
* Update app/controllers/concerns/caching_headers.rb
* Merge origin and add request_store gem
* Replace in Cache-Control header to support Nginx caching
* Add 'X-Accel-Expires' header for Nginx caching
* Remove max-age directive from remaining specs
* Update caching header specs to test against x-accel-expires header
* Rename FastlyHeaders to CachingHeaders, conditionally experiment with removing no-cache
We suspect that it is safe to remove `no-cache` entirely from the Cache-Control headers that are sent
along to Fastly, but there is no great way to confirm this hypothesis. We're testing this by experimenting
on one single article. We will conditionally default to the same headers that we send to Nginx, and send
those headers to Fastly (by removing `no-cache` and adding in `max-age`, which should be ignored since Fastly
also has Surrogate-Control headers added to it, which include a `max-age`, which Fastly should prioritize
over any other `max-age`.
Once we've confirmed that this doesn't cause issues on the Fastly side, we can remove this check and use
the same Cache-Control headers for both Fastly and Nginx.
* Add check for request.env[REQUEST_PATH].present?
2020-08-05 12:34:12 -07:00
Renamed from app/controllers/concerns/fastly_headers.rb (Browse further)
