Fix pipeline error and improve code base accessibility

[jacob-macleod]

There are several main tasks for this DevSecOps focused issue:

• ~Apparently, it's safe for the frontend to expose the API key. The following needs to be done:~
  • ~Investigate whether the same API key is used on the backend and frontend. If so, find out whether exposing the key will alow users to do what they want to the DB. If not, make the front end sign in method use the actual API key, hardcoded in a file~
• ~Make all API calls in frontend reference the deployed app (http://dolphin-flashcards.com) so that the frontend can be run independently of the local backend server. So the frontend should never need the backend server running locally. The url should be in a standalone file for easy access~
• ~Make the db class have a dev mode, where it reads and writes to a single json file, converting a data path ("my/data/path") to a json location. Add reading and writing this way. Use ChatGPT for this~
• ~Make it so by default when you clone the repo, it uses the local dev files, and in production it talks to firebase. Make it so you can make it talk to firebase yourself if you want~
• ~Use a smaller Linux image for the docker image, so it takes less storage. The pipeline failed due to storage - this should be fixed~
• ~Add a CONTRIBUTING.md file. This should explain how to contribute for frontend and backend, and explain the relationship between the two separate codebases. Since local files are now read from in dev for the backend, no firebase configuration should be needed. This should be explain, and a link given to explain how to setup your own test project. The frontend will use the real production code, from the public API~
• ~Add a DEPLOYING.md file that explains how to deploy with your own firebase server, and how contributing works - this info is included in CONTRIBUTING.md~
• ~Link to the two new markdown files from README.md~

This must be done before contributors can really work on code. Right now, the backend server must be running locally, connected to the live production database, to do any contributing

[jacob-macleod]

A different key is used on the backend.The firebase_confdig.json file is still used, as well as another file with a genuinely secret API key. Thus, according to https://firebase.google.com/docs/projects/api-keys, I can show it, so long as I'm not using:

• Firebase ML
• Firebase Authentication with the email/password sign-in method (atm I've got Google signin, so I can't add email and password while still exposing the key)
• A billable Google Cloud API. I don't think the firebase database counts So it should be ok. If someone sees this and thinks I'm making a mistake, please let me know!

According to https://infosecwriteups.com/is-it-safe-to-expose-your-firebase-api-key-bf2a318c0f29, people using the API key can make lots of sign in requests, but they can do that anyway using the app. The idea that it is safe is echoed by https://stackoverflow.com/questions/37482366/is-it-safe-to-expose-firebase-apikey-to-the-public, as does https://medium.com/@paulbreslin/is-it-safe-to-expose-your-firebase-api-key-to-the-public-7e5bd01e637b

[jacob-macleod]

The coding side of this is now done - next, the size of the docker image needs to be reduced

[jacob-macleod]

It looks like the installed node modules is the reason for the large docker image. I've made the pipeline remove this automatically. A MR will now be made to test the new pipeline