feat!: migrated secrets to a seperate file (#31)

* feat!: migrated secrets to a seperate file * chore: docs and cleanup --------- Co-authored-by: zleyyij <[email protected]> Co-authored-by: zleyyij <[email protected]>
r-Techsupport · Sep 10, 2023 · 078a980 · 078a980
1 parent 010caba
commit 078a980
Show file tree

Hide file tree

Showing 14 changed files with 295 additions and 107 deletions.
diff --git a/.DS_Store b/.DS_Store
diff --git a/.gitignore b/.gitignore
@@ -1,5 +1,6 @@
 node_modules
 config.jsonc
+secrets.jsonc
 target
 *.0x/
 docs/jsdoc/

diff --git a/Dockerfile b/Dockerfile
@@ -18,4 +18,4 @@ COPY target/ ./target/
 
 
 # Run it without compiling
-CMD ["make", "run"]
+CMD ["make", "prod-run"]
diff --git a/Makefile b/Makefile
@@ -21,6 +21,13 @@ start: build
 # instead of the compiled js
 	node --enable-source-maps ./target/core/main.js 
 
+# Start the bot, without compiling, running using the production node profile
+# (will start more slowly, but have better performance afterwords)
+# https://nodejs.dev/en/learn/nodejs-the-difference-between-development-and-production/
+# (will only work in linux)
+prod-run:
+	NODE_ENV=production node --enable-source-maps ./target/core/main.js
+
 # Compile code and run unit tests https://nodejs.org/api/test.html#test-runner
 test: build
 	node --test ./target/tests
@@ -50,7 +57,7 @@ docker-run:
 # -d: run in daemon mode and start in the background
 # --mount type=bind...: take the config file in this directory, and mount it to the equivalent directory in the docker container
 # turingbot: the container to run
-	docker run --rm --name turingbot -d --mount type=bind,source=$(pwd)/config.jsonc,target=/usr/src/turingbot/config.jsonc turingbot
+	docker run --rm --name turingbot -d --mount type=bind,source=$(pwd)/config.jsonc,target=/usr/src/turingbot/config.jsonc --mount type=bind,source=$(pwd)/secrets.jsonc,target=/usr/src/turingbot/secrets.jsonc turingbot
 
 # Make a bot docker container and start it in daemon mode
 docker-start: docker-build

diff --git a/config.default.jsonc b/config.default.jsonc
@@ -1,25 +1,10 @@
 {
-  /**
-   * https://discord.com/developers/docs/topics/oauth2
-   * https://discord.com/developers
-   * create new application -> bot -> new bot user -> oath2 -> bot -> administrator -> copy link
-   * rememember to set your bot intents
-   */
-  "authToken": "your-auth-token",
-  "applicationId": "",
-  // database configuration
-  "mongodb": {
-    // These are filled out using the settings from `k8s/dev.yaml`, but should probably
-    // be set to something different in prod
-    // If using Atlas, set the protocol to mongodb+srv://
-    // Otherwise set it to mongodb://
-    "protocol": "mongodb://",
-    "address": "mongodb.default.svc.cluster.local",
-    "username": "root",
-    "password": "root"
-  },
   // Specifically event logging
   "logging": {
+    // restrict this command to people with the `administrator` perm
+    "permissions": {
+      "requiredPerms": ["administrator"]
+    },
     /**
      * Different levels of verbose logging.
      *
@@ -41,67 +26,15 @@
       "userIds": [""],
       "verboseLevel": 1
     },
-
     "loggingChannel": {
       "loggingChannelId": "",
       "verboseLevel": 3
     }
   },
 
-  "testing": {
-    // The user ID for the bot test user
-    "userID": ""
-  },
-
   // The key for each module should match the one specified in the root module initialization
   // if the `enabled` key is missing, the extension will be disabled by default, and a warning issued
-
-  // --ALL IDS MUST BE STRINGS, NOT NUMBERS--
-
-  /*
-  Here's an example permissions config and boilerplate:
-  You can use this by setting the `permissions` key of each extension
-  to an object like this. It's not required for any of these keys to be set.
-  ```
-  "permissions": {
-    // a list of all possible permission restrictions
-    "requiredPerms": ["kick", "ban", "timeout", "manage_roles", "administrator"],
-    "allowed": {
-        // list of user IDs
-        "users": [],
-        // list of role IDs (or names? needs to be discussed)
-        "roles": [],
-        // list of channel IDs
-        "channels": [],
-        // a list of category IDs
-        "categories": [],
-    },
-    "denied": {
-        // a list of user IDs
-        "users": [],
-        // a list of role IDs
-        "roles": [],
-        // a list of channel IDs
-        "channels": [],
-        // a list of category IDs.
-        "categories": [],
-    }
-    // if you also want to restrict permissions per submodule, it can be done as below
-    "submodulePermissions": {
-      // each key in this object is the name of a submodule, so for a command like `/factoid all`, 
-      // you could restrict it with a key named `"all"`.
-      "<submodule_name>": {
-        // the same structure can be nested
-        "requiredPerms": [],
-        // you can also nest submodulePermissions to restrict a command 3 layers deep, like "/factoid all html"
-        "submodulePermissions: {
-          "<submodule_name>": {}
-        }
-      }
-    }
-  }
-    ```
-  */
+  // permissions are explained in the production environment doc
   "modules": {
     "logging": {
       "enabled": true,
@@ -112,9 +45,8 @@
       // communication channel on the left, logging channel on the right
       "channelMap": {
     },
-      // this map contains a list of channels that will not be logged. also populated by `logging populate`
-      "channelBlacklist": [
-    ]
+      // this array contains a list of channels that will not be logged. also populated by `logging populate`
+      "channelBlacklist": []
     },
     "factoid": {
       "enabled": true,
@@ -144,9 +76,7 @@
       "roleIdOnApprove": ""
     },
     "google": {
-      "enabled": true,
-      "ApiKey": "",
-      "CseId": ""
+      "enabled": true
     },
     // API key is shared with google
     "youtube": {
@@ -158,24 +88,12 @@
     "autopaste": {
       "enabled": true,
       // Make sure the ids are all strings, not numbers
-      "immuneRoleIds": [],
-      "maxLength": 100,
-      "pasteFooterContent": "",
-      "pasteApi": ""
-    },
-    "filter": {
-      "enabled": true,
-      "exemptRoles": []
-    },
-    "warn": {
-      "enabled": true,
-      "maxWarns": 3
-    },
-    "warns": {
-      "enabled": true
-    },
-    "unwarn": {
-      "enabled": true
+     "immuneRoleIds": [],
+     "maxLength": 100,
+     // optionally, include a footer for autopasted messages
+     "pasteFooterContent": "Note: long messages are automatically pasted",
+     // the URL of a valid linx paste server
+     "pasteApi": ""
     }
   }
 }
diff --git a/docs/guides/developing_modules.md b/docs/guides/developing_modules.md
@@ -158,6 +158,70 @@ const conch = new util.RootModule(
 );
 ```
 
+## Understanding Javascript Functions (and callbacks)
+There are a lot of different ways to define what's functionally (no pun intended) the same thing in Javascript. In Javascript, functions can be treated as values, so it's possible to use them as arguments, re-assign them, and store them as variables.
+
+```typescript
+// normal
+function hiThere(args) {
+  //code you want to run goes here
+}
+
+// while largely considered bad/dated practice, you can do this:
+// this is assigning hiThere to a function.
+const hiThere = function () {
+}
+
+// "callback" or arrow syntax is a shorthand way to define functions, it's commonly used to pass functions as arguments eg: iWantToRunThisCode(() => {})
+const hiThere = (args) => {
+  // code you want to run goes here
+};
+
+// if you only have one arg, although this is less commonly used, you can do this, and exclude parentheses:
+const hiThere = arg => {
+  // code you want to run goes here
+};
+
+// although a bit odd, a block and statement are usually interchangeable, so if you only want to run one statement, you can do that too
+// the return value will be the result of arbitrary statement
+const hiThere = arg => arbitraryStatement();
+
+// there's also filter syntax, where you return the result of a comparison
+const isHello = arg => arg === "hello";
+
+// these can also all be async:
+async function hiThere() {}
+const hiThere = async () => {}
+const hiThere = async arg => {}
+// and so on
+```
+
+### Callbacks
+It's possible to pass a function as an argument to another function.
+
+```typescript
+// this function accepts a callback
+function callAnotherFunction(functionToCall: () => {}) {
+  console.log('calling function');
+  functionToCall();
+}
+
+// here, we can pass a function as an argument
+callAnotherFunction(() => {
+  console.log('I got called!');
+});
+
+// because functions can also be treated as values, we can define a function, then pass it in
+function functionToCall() {
+  console.log('I got called, and passed as a variable!');
+}
+
+// excluding the parentheses means passing by value, not evaluating the function
+callAnotherFunction(functionToCall) {
+
+}
+```
+
 ## Using MongoDB
 MongoDB is the database of choice for this project, and it can be accessed by specifying it as a Dependency in the root module's constructor. This will disable your module if MongoDB is inaccessible.