feat ✨update to typescript

Author: ziracmo

.gitignore

@@ -1,2 +1,3 @@
 .vscode
 node_modules
+.history

crowdsec-docs/.npmrc

@@ -0,0 +1 @@
+v20.18.1

crowdsec-docs/babel.config.js

@@ -3,7 +3,7 @@ id: traefik
 title: Traefik
 ---
 
-import FormattedTabs from '@site/src/components/FormattedTabs'; 
+import FormattedTabs from '@site/src/components/formatted-tabs'; 
 
 # CrowdSec WAF QuickStart for Traefik
 

crowdsec-docs/docs/appsec/quickstart/traefik.mdx

@@ -3,7 +3,7 @@ id: getting_started
 title: Getting Started
 ---
 
-import AcademyPromo from '@site/src/components/AcademyPromo';
+import AcademyPromo from '@site/src/components/academy-promo';
 
 Welcome to CrowdSec!
 
@@ -15,8 +15,7 @@ To embark on your CrowdSec journey, the optimal starting point is to set up a co
 
 The CrowdSec console serves as a web-based interface enabling you to conveniently monitor all your CrowdSec instances from a centralized hub. To get started, simply [sign up here](https://app.crowdsec.net/signup).
 
-
-## Deploy 
+## Deploy
 
 ### Walkthrough
 
@@ -43,8 +42,9 @@ In our updated documentation, we now refer to CrowdSec as the "Security Engine"
 #### Prerequisites
 
 The Security Engine by default uses the following ports:
-  - 8080/tcp for the API
-  - 6060/tcp for the Prometheus metrics / Debugging
+
+-   8080/tcp for the API
+-   6060/tcp for the Prometheus metrics / Debugging
 
 If these ports are not available on your system, you can change them in the configuration file post installation. See [Configuration](/configuration/crowdsec_configuration.md) for more information.
 
@@ -55,15 +55,15 @@ Please note that the API is mandatory for your security engine, do not remove it
 For the most straightforward installation of the Security Engine, utilize the official repository, guaranteeing you'll constantly have the latest version.
 
 Please see the relevant documentation for your OS:
-- [Linux](/getting_started/install.mdx)
-- [FreeBSD](/getting_started/install_freebsd.md)
-- [Windows](/getting_started/getting_started_on_windows.md)
+
+-   [Linux](/getting_started/install.mdx)
+-   [FreeBSD](/getting_started/install_freebsd.md)
+-   [Windows](/getting_started/getting_started_on_windows.md)
 
 #### Installing from source
 
 Should you opt for a source-based installation, you can follow the steps outlined [here](/getting_started/install_source.mdx).
 
-
 ### Remediation Component
 
 After installing the Security Engine, you can proceed to install a Remediation Component, which is responsible for executing actions based on the decisions made by the Security Engine.
@@ -76,4 +76,4 @@ If you are uncertain about which one to install, please refer to our [Remediatio
 
 Since you created your account on the CrowdSec console, you can now [enroll your Security Engine to your account](https://app.crowdsec.net/security-engines?enroll-engine=true).
 
-To do so, you can find steps outlined [here](/u/getting_started/post_installation/console/#engines-page).
+To do so, you can find steps outlined [here](/u/getting_started/post_installation/console/#engines-page).

crowdsec-docs/docs/getting_started/getting_started.md

@@ -4,7 +4,7 @@ id: intro
 ---
 
 import useBaseUrl from "@docusaurus/useBaseUrl"
-import AcademyPromo from "@site/src/components/AcademyPromo"
+import AcademyPromo from "@site/src/components/academy-promo"
 
 # Security Engine Overview
 

crowdsec-docs/docs/intro.mdx

@@ -4,7 +4,7 @@ title: Creating parsers
 sidebar_position: 4
 ---
 
-import AcademyPromo from '@site/src/components/AcademyPromo';
+import AcademyPromo from '@site/src/components/academy-promo';
 
 ## Foreword
 
@@ -51,10 +51,8 @@ The error message can be useful when one wants to understand why the parser file
 
 ![Possible integration](/img/parser_creation/error_message.png)
 
-
 ## Pre-requisites
 
-
 1. [Create a local test environment](https://doc.crowdsec.net/docs/contributing/contributing_test_env)
 
 2. Clone the hub
@@ -63,7 +61,6 @@ The error message can be useful when one wants to understand why the parser file
 git clone https://github.com/crowdsecurity/hub.git
 ```
 
-
 ## Create our test
 
 From the root of the hub repository :
@@ -81,23 +78,20 @@ From the root of the hub repository :
 
 ## Configure our test
 
-
 Let's add our parser to the test configuration (`.tests/myservice-logs/config.yaml`). He specify that we need syslog-logs parser (because myservice logs are shipped via syslog), and then our custom parser.
 
 ```yaml
 parsers:
-- crowdsecurity/syslog-logs
-- ./parsers/s01-parse/crowdsecurity/myservice-logs.yaml
+    - crowdsecurity/syslog-logs
+    - ./parsers/s01-parse/crowdsecurity/myservice-logs.yaml
 scenarios:
 postoverflows:
 log_file: myservice-logs.log
 log_type: syslog
 ignore_parsers: false
-
 ```
 
-__note: as our custom parser isn't yet part of the hub, we specify its path relative to the root of the hub directory__
-
+**note: as our custom parser isn't yet part of the hub, we specify its path relative to the root of the hub directory**
 
 ## Parser creation : skeleton
 
@@ -110,29 +104,28 @@ onsuccess: next_stage
 name: crowdsecurity/myservice-logs
 description: "Parse myservice logs"
 grok:
-#our grok pattern : capture .*
-  pattern: ^%{DATA:some_data}$
-#the field to which we apply the grok pattern : the log message itself
-  apply_on: message
+    #our grok pattern : capture .*
+    pattern: ^%{DATA:some_data}$
+    #the field to which we apply the grok pattern : the log message itself
+    apply_on: message
 statics:
-  - parsed: is_my_service
-    value: yes
+    - parsed: is_my_service
+      value: yes
 ```
 
- - a [filter](/log_processor/parsers/format.md#filter) : if the expression is `true`, the event will enter the parser, otherwise, it won't
- - a [onsuccess](/log_processor/parsers/format.md#onsuccess) : defines what happens when the event was successfully parsed : shall we continue ? shall we move to next stage ? etc.
- - a `name` & a `description`
- - some [statics](/log_processor/parsers/format.md#statics) that will modify the event
- - a `debug` flag that allows to enable local debugging information
- - a `grok` pattern to capture some data in logs
-
+-   a [filter](/log_processor/parsers/format.md#filter) : if the expression is `true`, the event will enter the parser, otherwise, it won't
+-   a [onsuccess](/log_processor/parsers/format.md#onsuccess) : defines what happens when the event was successfully parsed : shall we continue ? shall we move to next stage ? etc.
+-   a `name` & a `description`
+-   some [statics](/log_processor/parsers/format.md#statics) that will modify the event
+-   a `debug` flag that allows to enable local debugging information
+-   a `grok` pattern to capture some data in logs
 
 We can then "test" our parser like this :
 
 ```bash
 ▶ cscli hubtest run myservice-logs
-INFO[01-10-2021 12:41:21 PM] Running test 'myservice-logs'                
-WARN[01-10-2021 12:41:24 PM] Assert file '/home/dev/github/hub/.tests/myservice-logs/parser.assert' is empty, generating assertion: 
+INFO[01-10-2021 12:41:21 PM] Running test 'myservice-logs'
+WARN[01-10-2021 12:41:24 PM] Assert file '/home/dev/github/hub/.tests/myservice-logs/parser.assert' is empty, generating assertion:
 
 len(results) == 2
 len(results["s00-raw"]["crowdsecurity/syslog-logs"]) == 3
@@ -153,9 +146,10 @@ Please fill your assert file(s) for test 'myservice-logs', exiting
 
 ```
 
-What happened here ? 
- - Our logs have been processed by syslog-logs parser and our custom parser
- - As we have no existing assertion(s), `cscli hubtest` kindly generated some for us
+What happened here ?
+
+-   Our logs have been processed by syslog-logs parser and our custom parser
+-   As we have no existing assertion(s), `cscli hubtest` kindly generated some for us
 
 This mostly allows us to ensure that our logs have been processed by our parser, even if it's useless in its current state.
 Further inspection can be seen with `cscli hubtest explain` :
@@ -184,10 +178,8 @@ line: Dec  8 06:28:43 mymachine myservice[2806]: accepted connection for user 't
 
 We can see that our log lines were successfully parsed by both syslog-logs and myservice-logs parsers.
 
-
 ## Parser creation : actual parser
 
-
 Let's modify our parser, `./parsers/s01-parse/crowdsecurity/myservice-logs.yaml` :
 
 ```yaml
@@ -197,26 +189,26 @@ name: crowdsecurity/myservice-logs
 description: "Parse myservice logs"
 #for clarity, we create our pattern syntax beforehand
 pattern_syntax:
-  MYSERVICE_BADPASSWORD: bad password for user '%{USERNAME:user}' from '%{IP:source_ip}' #[1]
-  MYSERVICE_BADUSER: unknown user '%{USERNAME:user}' from '%{IP:source_ip}' #[1]
+    MYSERVICE_BADPASSWORD: bad password for user '%{USERNAME:user}' from '%{IP:source_ip}' #[1]
+    MYSERVICE_BADUSER: unknown user '%{USERNAME:user}' from '%{IP:source_ip}' #[1]
 nodes:
-#and we use them to parse our two type of logs
-  - grok:
-      name: "MYSERVICE_BADPASSWORD" #[2]
-      apply_on: message
-      statics:
-        - meta: log_type #[3]
-          value: myservice_failed_auth
-        - meta: log_subtype
-          value: myservice_bad_password
-  - grok:
-      name: "MYSERVICE_BADUSER" #[2]
-      apply_on: message
-      statics:
-        - meta: log_type #[3]
-          value: myservice_failed_auth
-        - meta: log_subtype
-          value: myservice_bad_user
+    #and we use them to parse our two type of logs
+    - grok:
+          name: "MYSERVICE_BADPASSWORD" #[2]
+          apply_on: message
+          statics:
+              - meta: log_type #[3]
+                value: myservice_failed_auth
+              - meta: log_subtype
+                value: myservice_bad_password
+    - grok:
+          name: "MYSERVICE_BADUSER" #[2]
+          apply_on: message
+          statics:
+              - meta: log_type #[3]
+                value: myservice_failed_auth
+              - meta: log_subtype
+                value: myservice_bad_user
 statics:
     - meta: service #[3]
       value: myservice
@@ -227,19 +219,18 @@ statics:
 ```
 
 Various changes have been made here :
- - We created to patterns to capture the two relevant type of log lines, Using an [online grok debugger](https://grokdebug.herokuapp.com/) or an [online regex debugger](https://www.debuggex.com/) [2]
-)
- - We keep track of the username and the source_ip (Please note that setting the source_ip in `evt.Meta.source_ip` and `evt.Parsed.source_ip` is important [1])
- - We setup various [statics](/log_processor/parsers/format.md#statics) information to classify the log type [3]
-
 
+-   We created to patterns to capture the two relevant type of log lines, Using an [online grok debugger](https://grokdebug.herokuapp.com/) or an [online regex debugger](https://www.debuggex.com/) [2]
+    )
+-   We keep track of the username and the source_ip (Please note that setting the source_ip in `evt.Meta.source_ip` and `evt.Parsed.source_ip` is important [1])
+-   We setup various [statics](/log_processor/parsers/format.md#statics) information to classify the log type [3]
 
 Let's run out tests again :
 
 ```bash {13-20}
-▶ cscli hubtest run myservice-logs                    
-INFO[01-10-2021 12:49:56 PM] Running test 'myservice-logs'                
-WARN[01-10-2021 12:49:59 PM] Assert file '/home/dev/github/hub/.tests/myservice-logs/parser.assert' is empty, generating assertion: 
+▶ cscli hubtest run myservice-logs
+INFO[01-10-2021 12:49:56 PM] Running test 'myservice-logs'
+WARN[01-10-2021 12:49:59 PM] Assert file '/home/dev/github/hub/.tests/myservice-logs/parser.assert' is empty, generating assertion:
 
 len(results) == 2
 len(results["s00-raw"]["crowdsecurity/syslog-logs"]) == 3
@@ -291,8 +282,7 @@ line: Dec  8 06:28:43 mymachine myservice[2806]: accepted connection for user 't
 		└ 🔴 crowdsecurity/myservice-logs
 ```
 
-__note: we can see that our log line `accepted connection for user 'toto' from '192.168.1.1'` wasn't parsed by `crowdsecurity/myservice-logs` as we have no pattern for it__
-
+**note: we can see that our log line `accepted connection for user 'toto' from '192.168.1.1'` wasn't parsed by `crowdsecurity/myservice-logs` as we have no pattern for it**
 
 ## Closing word
 
@@ -309,4 +299,4 @@ See as well [this blog article](https://crowdsec.net/blog/how-to-write-crowdsec-
   title="More ways to learn"
   course="writing-parsers-and-scenarios"
   utm="?utm_source=docs&utm_medium=banner&utm_campaign=parser-page&utm_id=academydocs"
-/>
+/>

crowdsec-docs/docs/log_processor/parsers/create.md

@@ -4,7 +4,7 @@ title: Creating scenarios
 sidebar_position: 4
 ---
 
-import AcademyPromo from '@site/src/components/AcademyPromo';
+import AcademyPromo from '@site/src/components/academy-promo';
 
 :::caution
 
@@ -77,13 +77,13 @@ Let's add our parser and scenario to the test configuration (`.tests/myservice-b
 
 ```yaml
 parsers:
-  - crowdsecurity/syslog-logs
-  - crowdsecurity/dateparse-enrich
-  - ./parsers/s01-parse/crowdsecurity/myservice-logs.yaml
+    - crowdsecurity/syslog-logs
+    - crowdsecurity/dateparse-enrich
+    - ./parsers/s01-parse/crowdsecurity/myservice-logs.yaml
 scenarios:
-  - ./scenarios/crowdsecurity/myservice-bf.yaml
+    - ./scenarios/crowdsecurity/myservice-bf.yaml
 postoverflows:
-  - ""
+    - ""
 log_file: myservice-bf.log
 log_type: syslog
 ignore_parsers: true
@@ -126,16 +126,16 @@ We filter on `evt.Meta.log_type == 'myservice_failed_auth'` because in the parse
 
 We have the following fields:
 
-- a [type](/log_processor/scenarios/format.md#type): the type of bucket to use (trigger or leaky).
-- a [name](/log_processor/scenarios/format.md#name)
-- a [description](/log_processor/scenarios/format.md#description)
-- a [filter](/log_processor/scenarios/format.md#type): the filter to apply on events to be filled in this bucket.
-- a [leakspeed](/log_processor/scenarios/format.md#leakspeed)
-- a [capacity](/log_processor/scenarios/format.md#capacity): the number of events in the bucket before it overflows.
-- a [groupby](/log_processor/scenarios/format.md#groupby): a field from the event to partition the bucket. It is often the `source_ip` of the event.
-- a [blackhole](/log_processor/scenarios/format.md#blackhole): the number of minute to not retrigger this scenario for the same `groupby` field.
-- a [reprocess](/log_processor/scenarios/format.md#reprocess): ingest the alert in crowdsec for further processing.
-- some [labels](/log_processor/scenarios/format.md#labels): Some labels are mandatory and the scenario will not be validated by the Hub if they are missing. Don't forget to set `remediation: true` if you want the IP to be blocked by bouncers.
+-   a [type](/log_processor/scenarios/format.md#type): the type of bucket to use (trigger or leaky).
+-   a [name](/log_processor/scenarios/format.md#name)
+-   a [description](/log_processor/scenarios/format.md#description)
+-   a [filter](/log_processor/scenarios/format.md#type): the filter to apply on events to be filled in this bucket.
+-   a [leakspeed](/log_processor/scenarios/format.md#leakspeed)
+-   a [capacity](/log_processor/scenarios/format.md#capacity): the number of events in the bucket before it overflows.
+-   a [groupby](/log_processor/scenarios/format.md#groupby): a field from the event to partition the bucket. It is often the `source_ip` of the event.
+-   a [blackhole](/log_processor/scenarios/format.md#blackhole): the number of minute to not retrigger this scenario for the same `groupby` field.
+-   a [reprocess](/log_processor/scenarios/format.md#reprocess): ingest the alert in crowdsec for further processing.
+-   some [labels](/log_processor/scenarios/format.md#labels): Some labels are mandatory and the scenario will not be validated by the Hub if they are missing. Don't forget to set `remediation: true` if you want the IP to be blocked by bouncers.
 
 We can then "test" our scenario like this :
 
@@ -171,8 +171,8 @@ Please fill your assert file(s) for test 'myservice-bf', exiting
 
 What happened here ?
 
-- The scenario has been triggered and is generating some assertion (for functional test)
-- In production environment, an alert would have been send to the CrowdSec Local API.
+-   The scenario has been triggered and is generating some assertion (for functional test)
+-   In production environment, an alert would have been send to the CrowdSec Local API.
 
 We can again understand more of what is going on thanks to `cscli hubtest explain` :