fix: rectify the glee feats (#663)

docs/pages/authentication.md

@@ -19,12 +19,12 @@ export async function clientAuth({ parsedAsyncAPI, serverName }) {
 }
 ```
 
-Glee looks for authentication files in the `auth` directory by default but it can be configured using [glee config file](config-file).
+Glee looks for authentication files in the `auth` directory by default but it can be configured using [glee config file](env-vars-config).
 The name of the authentication file should be the name of the targeted server that the authentication logic should work for.
 
 ## Supported Authentication Values in asyncapi.yaml file
 
-AsyncAPI currently supports a variety of authentication formats as specified in the [documentation](https://www.asyncapi.com/docs/reference/specification/v3.0.0-next-major-spec.15#securitySchemeObject), however Glee supports the following authentication schemas.
+AsyncAPI currently supports a variety of authentication formats as specified in the [documentation](https://www.asyncapi.com/docs/reference/specification/v3.0.0#securitySchemeObject), however Glee supports the following authentication schemas.
 
 - userPassword
 - http ("bearer")
@@ -56,7 +56,7 @@ components:
 
 ```
 
-A sample `asyncapi.yaml` for a **client** that implements some of the requirements of the server above:
+A sample `asyncapi.yaml` for a **client** that implements some of the requirements of the server above is as follows:
 
 ```yaml
 ##client asyncAPI schema
@@ -81,7 +81,7 @@ components:
 
 ```
 
-Glee can act as both a server and a client. Hence, the need for `serverAuth` and `clientAuth`. Glee acts as a client when the server name is included in the `x-remoteServers` property in the `asyncapi.yaml` file.
+Glee can act as both a server and a client. So the need for `serverAuth` and `clientAuth`. Glee acts as a client when the server name is included in the `x-remoteServers` property in the `asyncapi.yaml` file.
 
 When Glee acts as a client, it can connect to a Glee server, and when Glee acts as a server it accepts connections from other Glee clients. Hence a Glee application can both accept connections from clients while also sending requests to other Glee applications (servers) at the same time.
 
@@ -109,19 +109,19 @@ export async function serverAuth({ authProps, done }) {
   if (isValidUser(authProps)) {
     done(true);
   } else {
-    done(false, 401, "Unauthorized");
+    done(false);
   }
 }
 ```
 **Parameters for done():**
 
-- Authentication Result (Boolean): true for success, false for failure.
+*Authentication Result (Boolean): true for success, false for failure.*
 
 When `true` is passed to the done parameter, the server/broker knows to go ahead and allow the client to connect, which means authentication has succeeded. However if the `done` parameter is called with `false` then the server knows to throw an error message and reject the client, which means authentication has failed.
 
 `done()` should always be the last thing called in a `serverAuth` function, Glee won't execute any logic beyond the `done()` call.
 
-### authProps
+#### authProps
 
 `authProps` implements a couple of methods that allows the server to retrieve the authentication parameters from the client, below are the current available methods;
 
@@ -134,7 +134,6 @@ export async function serverAuth({ authProps, done }) {
   authProps.getToken()
   authProps.getUserPass()
 
-  // done(false, 401, "Unauthorized");
   done(false)
 }
 ```
@@ -173,7 +172,7 @@ export async function clientAuth({ serverName }) {
 }
 ```
 
-**The name of the authentication parameters should be the same as the names specified in the `asyncapi.yaml` file.**
+The name of the authentication parameters should be the same as **the names specified in the `asyncapi.yaml` file.**
 
 | auth type                             | values                                                                 |
 | ------------------------------------- | ---------------------------------------------------------------------- |

docs/pages/bearerToken.md

@@ -5,7 +5,7 @@ weight: 80
 
 ## Getting started with Bearer Token authentication
 
-Bearer Token authentication is one of the most popular forms of authentication and is widely used because of its percieved security. This guide will walk through how to implement bearer token authentication in Glee.
+Bearer Token authentication is one of the most popular forms of authentication and is widely used because of its perceived security. This guide will walk through how to implement bearer token authentication in Glee.
 
 A sample `asyncapi.yaml` for a server with security requirements and user password security scheme is shown below:
 
@@ -61,7 +61,7 @@ components:
 
 ```
 
-**The Client asyncapi.yaml file does't need to implement all the security requirements in the server, it only needs to implement the ones that it uses like &*http (bearer token)* here.**
+The Client asyncapi.yaml file **does't need to implement all the security requirements in the server, it only needs to implement the ones that it uses like *http (bearer token)* here.**
 
 ### Client Side
 
@@ -103,7 +103,7 @@ export async serverAuth({ authProps, done }) {
 
 ```
 
-`getToken()` return a string which contains the token that was sent from the client.
+So, `getToken()` returns a string which contains the token that is sent from the client.
 
 
 

docs/pages/intro-auth.md → docs/pages/glee-auth-intro.md

@@ -3,20 +3,20 @@ title: 'Introduction to Glee Authentication'
 weight: 60
 ---
 
-Glee comes with Authentication features which help you erifying the identity of users or entities attempting to access a system or application. It ensures that only authorised individuals or systems are granted access, protecting against unauthorised intrusions and data breaches. Glee simplifies this vital process by offering multiple authentication methods, each tailored to different use cases:
+Glee comes with Authentication features which help you verifying the identity of users or entities attempting to access a system or application. It ensures that only authorised individuals or systems are granted access, protecting against unauthorised intrusions and data breaches. Glee simplifies this vital process by offering multiple authentication methods, each tailored to different use cases. Following methods are the different ways to sheild your application access.
 
-## Authentication Using Authentication Functions:
+### Authentication Using Authentication Functions:
 Glee allows you to implement custom authentication logic by utilising authentication functions. This flexible approach enables developers to craft tailored authentication mechanisms, ensuring that access to resources is controlled precisely as required.
 
 
-## HTTP Bearer Token Authentication:
+### HTTP Bearer Token Authentication:
 In today's API-driven world, bearer token authentication is a widely adopted method. Glee supports this approach, allowing clients to present a token as proof of their identity, thus ensuring secure and efficient access to resources.
 
-## HttpApiKey Authentication:
+### HttpApiKey Authentication:
 Glee's authentication suite includes support for API key authentication, which is vital for protecting web APIs. By using API keys, you can regulate access to your services, making it an essential component of your application's security strategy.
 
-## Username and Password Authentication:
+### Username and Password Authentication:
 Traditional yet still crucial, username and password authentication remains a reliable option within Glee's toolkit. This method allows users to access systems or applications by providing their unique credentials, ensuring a familiar and straightforward login experience.
 
-## Summary
+#### Summary
 Glee's authentication features not only provide layers of security but also offer the flexibility needed to meet your unique requirements. Whether you're developing a web application, a mobile app, or any other application, Glee's authentication methods empower you to tailor your security measures to suit the demands of your project. With Glee, you can build and maintain a secure digital environment, ensuring that only authorised users and systems gain access, protecting your valuable data and resources.

docs/pages/httpApiKey.md

@@ -64,7 +64,7 @@ components:
 
 The `httpApiKey` could be in either the header or query parameter.
 
-**The Client asyncapi.yaml file does not need to implement all the security requirements in the server, it only needs to implement the ones that it uses like *httpApiKey* here.**
+The Client asyncapi.yaml file **does not need to implement all the security requirements in the server, it only needs to implement the ones that it uses like *httpApiKey* here.**
 
 ### Client Side
 
@@ -95,7 +95,7 @@ From the server `asyncapi.yaml` file above, create a file named `trendingAnimeSe
 touch auth/trendingAnimeServer.ts
 ```
 
-On the server side, you can retrieve the values as follows
+On the server side, you can retrieve the values as follows:
 
 ```js
 
@@ -107,4 +107,4 @@ export async serverAuth({ authProps, done }) {
 
 ```
 
-`getHttpAPIKeys(name)` takes a name parameter to specify the name of the httpApiKey that is desired. Then it returns an object containing the httpApiKey value that was sent from the client.
+So, `getHttpAPIKeys(name)` takes a name parameter to specify the name of the httpApiKey that is desired. Then it returns an object containing the `httpApiKey` value that is sent from the client.

docs/pages/userPassword.md

@@ -32,7 +32,7 @@ components:
 
 ```
 
-A sample `asyncapi.yaml` for a client that implements some of the requirements of the server above:
+A sample `asyncapi.yaml` for a client that implements some of the requirements of the server above is as follows:
 
 ```yaml
 ##client asyncAPI schema
@@ -103,4 +103,4 @@ export async serverAuth({ authProps, done }) {
 
 ```
 
-`getUserPass()` returns an object containing the username and password that was sent from the client.
+So, `getUserPass()` returns an object containing the username and password that is sent from the client.