closes#12244
As per RFC 6454 the Origin header MUST be set to the string 'null' when
in a "privacy-sensitive" context. We were not handling this string and
this was causing errors. This commit updates all checks of the 'Origin'
header to treat the value 'null' as if the header was not present.
ref: https://tools.ietf.org/html/rfc6454#section-7.3
- There were various cases where it was possible to trigger a private site to display a 404 instead of redirecting to /private/
- Private mode was also not always displaying the correct robots.txt
- This PR includes tests for all cases in test/frontend-acceptance/default_routes_spec.js & where possible the unit tests have also been updated for completeness
- Fixing the 404 issues required
- Better handling of paths using req.path instead of req.url in filterPrivateRoutes
- Additional error handling, to cover the case that a tag/author RSS feed does not exist
- Fixing the robots.txt required the order of middleware to be changed, so that private blogging gets a chance to render first
- NOTE private blogging is the only app with a setupMiddleware function so nothing else is affected
* moved `server/config` to `shared/config`
* updated config import paths in server to use shared
* updated config import paths in frontend to use shared
* updated config import paths in test to use shared
* updated config import paths in root to use shared
* trigger regression tests
* of course the rebase broke tests
- Added a wrapper around express.Router to our shared/express util
- Also export static and _express
- Use this shared util everywhre, meaning express is only used directly in this one file
- ATM this file is mostly an experiment / debug helper, it might be removed again later
- The aim is to have a minimal framework wrapping express that allows us to:
- reduce our usage of express() in favour of Router()
- unify some of our duplicated logic
- fix some structural issues e.g. Sentry
- make it easier to understand the codebase
- Clarify that the parent app has 2 distinct parts: backend and frontend
- Frontend app takes members and site apps + the frontend SSL redirect middleware
- Backend app already has admin + API (and the SSL redirect needs significant work)
- There's a lot more to do here, but this increases clarity
- create a new app for the /members/ endpoint
- moved all /members/ routes and middleware onto this app
- helps to separate members and frontend/site logic so we can start to decouple things more
- Magic link token handling doesn't need to be global, this couples the system to the frontend, which isn't necessary
- Instead, we create a session from the token, and redirect to the frontend
- Move res.locals.members setting into existing middleware function instead of having it separate
- The existing createSessionFromToken was actually doing two things behind the scenes
1. Handling the ?token from the magic link and creating an actual session (mounted globally, which is not necessary)
2. Loading an existing session so that a member is logged in to the frontent
- IMO 1. is part of members, and doesn't need to be global
- IMO 2. is part of the frontend. It does need to be global but should NOT be hidden away behind the token middleware, as it wasn't clear what this was doing
- added core/shared to watched folders in grunt
- moved sentry to shared
- moved express initialisation to a shared file
- always set trust proxy + sentry error handler
- use this new express init everywhere, and remove duplicate trust proxy and sentry error handler code
- we had urlRedirects, urlRedirects.adminRedirect and adminRedirects
- all do kinda similar things, but for different contexts so for now I've done a minimal renaming for clarity
- and updated some comments!!
- also removed totally unnecessary if res.isAdmin clause, as we don't use that, and it was never true
- cache-control had some logic in it for private blogging + similar logic exists for members in site/app
- having it in 2 places is weird, and having it inside the mw makes the mw less generic/reusable
- instead of requiring config inside the middleware, we pass config in for the one case where this is used
- fixed tests that didn't test anything 🙈
refs https://github.com/TryGhost/members.js/issues/6
This exposes an endpoint on site url (`/members/ssr/member`) to get member's data in exchange for their session/identity on a theme when they are logged in. It essentially uses the same logic and data which is passed down to theme through handlebar helpers, and is used by members.js script to load member data.
- Moved serve-public-file from shared to site as it is not shared
- This file is only used in one place, this updates the code structure to reflect this
- This is one of many similar changes needed to make it easier to refactor to the existing setup
- Moved handle-image-sizes from shared to site as it is not shared
- This file is only used in one place, this updates the code structure to reflect this
- This is one of many similar changes needed to make it easier to refactor to the existing setup
- Moved static-theme from shared to site as it is not shared
- This file is only used in one place, this updates the code structure to reflect this
- This is one of many similar changes needed to make it easier to refactor to the existing setup
- Moved serve-favicon from shared to site as it is not shared
- This file is only used in one place, this updates the code structure to reflect this
- This is one of many similar changes needed to make it easier to refactor to the existing setup
- Moved admin-redirects from shared to site as it is not shared
- This file is only used in one place, this updates the code structure to reflect this
- This is one of many similar changes needed to make it easier to refactor to the existing setup
- the helper dir also contained some code used with helpers - utils and helper-helpers?
- the goal here was for helpers to be the only thing in their folder so we can look at moving them out
- all other code has been moved to services/themes for now, which is not the right place either
- services/themes is a catch-all for theme storage, loading, validation, rendering and more, needs to be broken down
- Apps are marked as removed in 3.0, never officially launched and have been deprecated for at least 2 years.
- We've slowly removed bits that got in our way or were insecure over time meaning they mostly didn't work
- This cleans up the remainder of the logic
- The tables should be cleaned up in a future major
- Apps are marked as removed in 3.0, never officially launched and have been deprecated for at least 2 years.
- We've slowly removed bits that got in our way or were insecure over time meaning they mostly didn't work
- This cleans up the remainder of the logic
- The tables should be cleaned up in a future major
refs 91984b54ca
- For request effieciency we should be using a minified file just like we did previously with `ghost-sdk.js`
- Modified 'max-age' caching header to 1 year for both minified and non-minified files as thay won't affect dev environment and should be beneficial for self-hosting instances that don't use minification
- Along the way corrected an extra 301 redirect because `/public/member.js` path wasn't using a bakslach in the end.
no issue
- serving of our public asset images was broken
- we were reading the binary file in as a string so we could do url transforms, this meant data was lost/corrupted and browsers could not display the served data
- we were using the wrong mime-type for pngs which meant browsers were triggering downloads rather than displaying images (at least when accessed directly)
- updates uses of `servePublicFile` to have the correct png mimetype
- adjusts `servePublicFile` to treat any mime type starting with `image` as a binary file, passing the file directly through express using `res.sendFile` and skipping the in-memory content caching which is mostly only useful for text files with URL transforms
This reverts commit 6e024331eb.
Temporarily reverting whilst we investigate an issue with Sentry and running Ghost via Ghost-CLI.
Ghost-CLI initiated boot was failing when Sentry was installed due to what appears to be `process.cwd()` returning `undefined` here https://github.com/TryGhost/Ignition/blob/master/lib/config/index.js#L26
no-issue
Our function for determining cors options created a new instance of URL
without wrapping it in a try/catch which meant any failures to parse the
URL bubbled down as a 500 error.
500 errors are commonly used for alerting at the infrastructure level,
and this error is definitely one caused by a badly configured client, so
we wrap the construction and crap out with a Bad Request Error (HTTP
400) if it fails.
no-issue
This name `login` was misleading as this middleware didn't login
members, that was handled by the `authentication` middleware,
specifically `exchangeTokenForSession`
no issue
- In order to keep site/app.js module tidy and less coupled with members module we need to extract some of the functionality where it belongs conceptually
- Added "members enabled check" middleware to stripe webhook endpoint
- Reshuffled members middleware so that siteApp is in control of mounting points. This is meant to be a more explicit way to see which endpoints are being handled by members middleware
- Extracted member-specific public file middleware
- Unified use of `labs.member` alias method. Done for code style consistency
- Added basic members' test suite. This is a base we could work from when more modifications are needed
- Removed route handler for unexisting members file "members-theme-bindings.js". Calling this route otherwise causes a 500. Looks like a leftover from 49672a1e4d
- This is a fairly temporary state
- It at least removes the themeService require from inside the routingService
- Requires us to pass the routingService the desired API Version...
- We're working towards having the entire frontend respect the theme API version by having it passed around everywhere
no-issue
This also adds a basic check before handing of to the members-ssr
module, this should make logs a little less noisy and only log warnings
if a token was passed and that token was invalid/incorrect.
no issue
- Removed v0.1 controllers
- Removed 0.1 API unit tests
- Removed 0.1 API app and mount point
- Removed leftover use of v0.1 in entry-lookup test suite
- Removed frontend client API enpoints and related code (middleware)
- Fixed prev/next test suites to use v2 API
- Set default API version to explicit v2 in UrlUtils
- Removed v0.1 API regex from public files middleware
no issue
- `vhost` as used in b46f9b1dc2 does not pass down the `trust proxy` setting to child apps so it's required to be called explicitly in each child app
- fixed URLs being output as http:// instead of https:// when the front-end is accessed with `x-forwarded-proto: 'https'`
no issue
- As v0.1 API is dropped there is no need to keep an API client around
- Removed references to ghost-sdk in regression test suite
- Removed routes to /public/ghost-sdk.js
- Removed reference to ghost-sdk in grunt build process
closes https://github.com/TryGhost/Ghost/issues/11078
Problem:
- the admin client makes an XHR request to the `/private/` endpoint when a private site is configured
- when a separate admin URL is configured this was causing 500 errors in the admin client because missing CORS headers on the endpoint was causing browsers to abort the request
- browsers will also look at the CORS headers on any resources that are the result of a redirect and abort the request if they do not allow cross-origin requests, this means allowing all requests on `/private/` is not enough
Solution:
- uses the `cors` middleware with a dynamic options function for the whole of the front-end site app
- dynamic options function allows the following requests through:
- same-origin (browsers and non-browser agents will not send an `Origin` header)
- origin is `localhost` or `127.0.0.1` with any protocol and port
- origin matches the configured `url` hostname+port on any protocol
- origin matches the configured `admin:url` hostname+port on any protocol
