cowlingj / ecommerce-backend Goto Github PK

As a hacker, I want to exploit known vulnerabilities within Docker images, so that I can break into and control the system.

• Look at Snyk vulnerabilities in Docker images
• Upgrade images where necessary
• Note not all of an images vulnerabilities will be exploitable

User Story

As a malicious user, I want to access the CMS, so I can change the content of the store.
[User story the same as #27 ]

Acceptance Criteria

• Remove hardcoded credentials from CMS
• Add credentials to helm values (without defaults)

Notes

relates to: #27

the common charts are used to create resources with a standardised set of values. This will make it easier to create new resources and customise charts.

As a store browser,
I want to see what products are available,
So that I can find products I like

As a developer, I expect the charts to use the standard values normally, enabled, conditions, tags

Docs

• v2
• v3 (wording's changed, but looks like impl hasn't)

This would need a set of tags like needs<Dependency> or <chart>Needs<Dependency> or <chart>InstallDependencies, then dependencies could be bundled within subcharts without causing multiple instances or clashes

As a store engineer, I would prefer an image I'm more familiar with, so that I trust it and can more confidently extend it.

• copy init and db images pattern used with postgres

A /packages directory could be where all my reusable bits of code live so that I could use them across services and even on the client (the client should get them from git, not through the file system).
An example would be where my graphql schema lives, that way both client and service can keep a copy that is automatically versioned.

As a store engineer, I want to be able to have the backend deploy itself to a cluster (that I can deploy a frontend to), so that I don't have to write all the configuration for the cluster.

Relates to #20, #17, and #14

As a store owner, I want an up to date admin interface, so that it's better to use and more secure.

• The differences between v4 and v5 need to be checked out to know how big and how much value this ticket carries
• The most important area is probably security updates, but anything high risk will be fixed for v4 according to github

As a store owner, I want to be able to access admin features of the store securely, so that only I can make changes to the store.

• Get image running successfully
• Does fusionauth fit my needs

Currently the CMS exposes an endpoint designed to be accessed directly, this isn't desirable since I'm not in control of the api, a solution to this would be to put a reverse proxy (or many) in front of it's API endpoint. This way I only expose the parts of the schema I want, and I don't need to worry about knowing how keystone names things.

As a starting point look into schema stitching and apollo-link

• https://hasura.io/blog/the-ultimate-guide-to-schema-stitching-in-graphql-f30178ac0072/#0f33

As a store owner, I want the option to use a hosted cms so that i can reduce my hosting costs.

Options

• Prismic
• Hasura Hasura sits on top of postgres, it's not hosted
• Contentful Pricing limits types
• Netlify CMS Git based, will require setting and managing that
• DatoCMS Pricing limits types
• Storyblock

Basically add a proxy to one of them, this could also proxy calls to keystone in order to have 1 CMS API.
This is a good example of the (internal) flexibility of the backend

As a malicious user, I want to access the graphql endpoint, so that I can view and change data in the store.

• graphql should be a separate app running in the same process

As a store owner, I want the CMS to be faster, so that I can make changes to configuration quickly and easily

• the most likely culprit is a strict cpu limit (there's a chance CMS could have a greedy or spiky cpu consumption)

setup Istio to pass auth through FusionAuth (protecting cms)

As a store browser,
I want to get detailed information about a single product,
So that I can make an informed choice on going to the store and buying

Since the backend has a fixed API (e.g. host/products, host/cms, etc.), the ingress resources currently in the reference implementation should be moved into the repo (probably under /helm/charts). This means deployment of the backend would need no additional config than what is passed to the umbrella helm chart.

Using a tool like yoeman or a custom npm initializer (yoeman is platform-agnostic I believe), create a template service using apollo and typescript as a base for all other projects, in order to make creating new services easier.

As a store engineer, I want some default routes set up for the backend, so that the system "works out of the box".

• istio routing added in helm package
• later there could be an option for non-istio routing

To support cowlingj/Uni-Cycle#10
Add events in the CMS, that way the store will have real data

As a store engineer, I want to be able to have a "one package deployment" of the whole backend, so it's easier for me to configure and deploy.

• there should be one "ecommerce-backend" package
• all configuration should be on the umbrella package

Yaml anchors might help with the configuration

relates to #62

I want to be able to create arbitrary lists using all my lists using config files, but I at least want to be able to add items to the database using config files.

One alternative could be to create a library for creating items that don't exist.

Event title looks like a cms key type, needs to be just a string

As a store engineer, I want to make sure the CMS is set up correctly and not giving me warnings about session storage memory leaks, so that I don't later get hit with unexpected resulting bugs.

• Look into warning
• If using fusionauth+istio I won't need to even bother with cookies/session storage

As a store owner, I want my data to be persisted even if the backend needs to restart, so that I don't lose any data.

• PV, PVC, what does terraform and GCP do about this

As a store owner, I want a product service that doesn't require external services, so that I can have full control over my products within the backend.

Could use JSON file(s) or mongodb as a backend for the service

As a store engineer, I want to access docker images, so that I can deploy a store.

• for now, manually deploy images, (ci/cd to come later)

relates to #3

using github actions 🎉

As a store owner, I want my CMS to be secure by default, so that I don't run the risk of a malicious user getting a hold of my data and being able to change it.

• some form of helm configuration to route requests via fusionauth before the CMS

relates to #16

As a malicious user, I want to access the CMS, so I can change the content of the store.

• The admin CMS endpoint should be protected by istio and fusionauth
• No authentication will be needed inside the CMS