"Popular posts" feature for Ghost(Pro)

It’s been asked many times and the staff’s response has been

This doesn’t work for Ghost(Pro) users.

  1. Client side helpers go into core/server/helpers which is inaccessible to Ghost(Pro) users. Even if the client helper is shoved into themes,

  2. there’s no place to store secrets. The credentials for fetching the view data (from Google Analytics for example) must be stored at a place accessible by the helper but not by the public. There aren’t any places in Ghost(Pro) for the secrets.

Due to these two limitations, “popular posts” feature can’t be implemented for Ghost(Pro) users. As such, ghost.org is the only party who can provide a solution for this.

Client-side in this case refers to scripts that run in the web browser, not server-side scripts or helper files.

The secrets would be stored in the mentioned microservice, there are no helpers involved.

My mistake on the wordings. I meant client side as is us the Ghost(Pro) user’s side, but I’ve used the wrong term to describe it.

Can you please elaborate? Where would the microservice live? Do you mean that we’d need to set up a service for this? Even if I do, I’d need a secret to access that microservice wouldn’t i?

This is one of the most popular implementation for using Google Analytics with Ghost (which I’m pretty sure you’ve seen), and that script is designed to go into core/server/helpers. This obviously doesn’t work for Ghost(Pro).

Another example of secret management pain points

To be clear, there’s a difference between secrets management and key management, especially in this context - secrets cannot be exposed, so they wouldn’t be used in a theme, while keys sometimes can be (in the example you linked to, the keys are public - one was for Google Books (which should be origin locked), and the other for the Content API (which is considered public))

I understand what you’re saying but those keys aren’t public. We can make repeated API calls with the keys, get them rate limited, and break the site.

A key having access to only public data doesn’t make the key itself public. Rather, a key is public only when it’s meant to be used by the public - in which case, why would you have a key at all?

Because of this, all API keys are private by definition. Some are more resilient to abuse than others but that doesn’t make them not private.

Ghost users can manage private keys through environment variables and server side scripts (and possibly origin locking if the API endpoint supports it and your server IP is static). Ghost(Pro) however doesn’t provide a way to manage private keys.

ghost.org is the only one who control the servers and the software, which why only they can solve this. Until this is provided, Ghost(Pro) users are forced to make insecure API calls.

Your “example” is a topic which was resolved based on secrets being misused and not needed in the first place.

It really doesn’t seem like you understand what you’re asking. Kevin’s answer in the previous topic was correct. If you want to build a popular posts list then you can:

  1. Write one statically - popular posts typically don’t change that often
  2. Query an external analytics service which provides that data by API
  3. Build a microservice, in its own environment, which returns this data without any authentication required.

All of these options are equally compatible with Ghost, regardless of where it’s hosted. There is no difference.