The serverquery from ihastaco

Bot Occasionally Fails to Update Embeds

In some instances, the ServerQuery bot fails to update embeds as expected. This problem is likely associated with recent changes in the error handling logic, where rate limit errors could be misinterpreted as an indication that a message does not exist.

This problem can result in outdated or missing information in the embeds, which can negatively impact the user experience and the bot's reliability.

We need to investigate the root cause of these missed updates and adjust the error handling logic as necessary to ensure that rate limit errors do not inhibit the bot's ability to update embeds.

Steps to Reproduce:

Start the ServerQuery bot and let it run over a period of time.
Monitor the bot's activity to check if any embed updates are missed.
- You can observe this by checking multiple bot embeds and viewing the timestamps. In my observations, I have seen a delay of up to a minute.
- The severity of this issue can escalate as more servers are added to the bot's database.

Expected Outcome:
The bot should consistently update all embeds, ensuring that the most recent and accurate information is always displayed.

Actual Outcome:
The bot occasionally misses updating embeds, which can lead to potential information gaps or outdated data. There's a possibility that this could be due to the bot encountering a rate limit when attempting to update the embeds, but misinterpreting the rate limit error as an indication that the message doesn't exist.

Possible Solution:
One potential solution could be to increase the number of attempts. This would enhance the chances of a successful update before the bot gives up. Another approach could be to introduce a delay between attempts, such as 1 second. This could potentially help avoid hitting rate limits by spacing out the requests over a longer duration.

While neither of these fixes will address the underlying issue, they can help mitigate its impact while the root cause is being investigated. In the meantime, I am working on developing a logging system that will aid in identifying and understanding these types of issues.

Bot stopped updating embeds completely

I’m at work so I will be updating this more later, and I can’t look into it at the moment.

I’ve noticed that the bot stopped, updating embed right at 3:55 am this morning, I’m hoping it crashed the server as the login system isn’t set up yet so I can search through the console screen to see what caused the issue

I think it maybe the bot lost connection to the internet as I haven’t seen this issue

Sharding Worker Keeps Closing - Unhandled Promise Rejection

I have encountered an issue where the sharding worker consistently closes, leading to an unhandled promise rejection. The error message reported is as follows:

_latest.log

[ 2023-08-02T22:59:20.213Z ] | [ ERROR ] | Unhandled promise rejection: {
  "code": "ShardingReadyDied"
}

Console

[ 2023-08-02T23:07:58.758Z ] | [ ERROR ] | Unhandled promise rejection: {
  "code": "ShardingReadyDied"
}
E:\_Bots\ServerQuery - Node.js\discord\node_modules\@discordjs\ws\dist\index.js:1363
      throw new Error(
            ^

Error: Not enough sessions remaining to spawn 1 shards; only 0 remaining; resets at 2023-08-03T07:27:41.934Z
    at WebSocketManager.connect (E:\_Bots\ServerQuery - Node.js\discord\node_modules\@discordjs\ws\dist\index.js:1363:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async WebSocketManager.connect (E:\_Bots\ServerQuery - Node.js\discord\node_modules\discord.js\src\client\websocket\WebSocketManager.js:206:5)
    at async Client.login (E:\_Bots\ServerQuery - Node.js\discord\node_modules\discord.js\src\client\Client.js:226:7)

This issue is critical, as it interrupts the normal functioning of the bot and may lead to unexpected behavior or downtime.

Steps to Reproduce:

Start the bot with sharding enabled.
Monitor the logs for the error message.
Observe the sharding worker's termination.

Expected Outcome:
The sharding worker should remain active and handle requests without any unhandled promise rejections.

Actual Outcome:
The sharding worker closes unexpectedly, resulting in an unhandled promise rejection with the error code "ShardingReadyDied."

Possible Solution:
Investigate the root cause of the "ShardingReadyDied" error and implement error handling to prevent unhandled promise rejections. The solution may involve analyzing the sharding implementation, identifying the specific scenario that leads to this error, and applying the necessary fixes.

Add Error Handling to Prevent Server Crashes

In the current implementation of ServerQuery, an error during the reading or writing of a file can cause the entire server to crash. This is because the errors that occur during fs.readFile and fs.writeFile operations are not caught and handled, leading to unhandled exceptions that can terminate the server.

This issue can potentially make the server vulnerable to Denial of Service (DoS) attacks, as a malicious user might be able to cause an error that crashes the server.

To resolve this issue, we need to add error handling to all file operations to prevent unhandled exceptions from crashing the server. If an error occurs, it should be logged and an appropriate error response should be sent back to the client.

Steps to Reproduce:

Start the ServerQuery server.
Make a POST request to the /write-notification-settings/:guildID/:serverUUID endpoint with a guildID and serverUUID that do not exist in the servers.json file.

Expected Outcome:
The server should handle the error gracefully, log the error, and send back an error response to the client.

Actual Outcome:
The server crashes due to an unhandled exception.

Suggested Fix:
Add error handling to the fs.readFile and fs.writeFile callbacks. If an error occurs, log it and send an error response to the client. This will prevent unhandled exceptions from crashing the server. Refer to this post for best practices on error handling in Node.js.

Relevant Example Code Snippet:
See postRoutes.js

router.post('/write-notification-settings/:guildID/:serverUUID', (req, res) => {
    const { guildID, serverUUID } = req.params;
    const notificationSettings = req.body;

    fs.readFile('./public/servers.json', 'utf8', (err, data) => {
        if (err) throw err;  // Unhandled exception

        // rest of the code...

        fs.writeFile('./public/servers.json', JSON.stringify(servers, null, 2), 'utf8', (err) => {
            if (err) throw err;  // Unhandled exception

            res.json({ message: 'Notification settings written.' });
        });
    });
});

Trend Line Data Does Not Affect Graph Height

In the current implementation of ServerQuery, the trend line data does not influence the height of the graph. Instead, the graph's height is determined solely by the maximum player count multiplied by two. This could lead to a misleading representation of the trend data, as the trend line may appear less prominent on the graph than it should be.

To enhance the accuracy and readability of the graph, the trend line data should be considered when determining the graph's height.

Steps to Reproduce:

Run the ServerQuery bot and let it gather data.
Observe the graph height and its relation to the trend line data.

Expected Outcome:

The graph height should adapt to the larger of the two values: the maximum player count (doubled) or the trend line data.

Actual Outcome:

The graph height is only influenced by the maximum player count (doubled), and does not adjust to accommodate the trend line data.

Suggested Fix:

Adjust the graph generation logic to consider both the maximum player count and the trend line data when setting the graph height. The graph height should be set to the larger of these two values to ensure an accurate and proportional representation of the trend data.

Dashboard Check for Channel Permissions When Adding a New Channel

To improve the user experience and prevent potential issues when adding a new channel, we should add a permissions check in the dashboard. This check would verify whether the channel's permissions are correctly set for the bot to be able to send embeds.

If the permissions are not set correctly, an alert would pop up to notify the user. The alert would provide instructions on how to adjust the permissions so that the bot can function properly. This would save users from having to troubleshoot why the bot isn't sending embeds to the new channel.

The permissions that need to be checked are:

View Channel
Embed Links
Attach Files
Read Message History

Benefits:
Implementing this feature would provide several benefits:

Prevent potential issues with bot functionality in new channels
Save users time by providing clear instructions on how to set channel permissions for the bot
Improve the user experience by providing immediate feedback on channel setup

Implementation:

This feature could be implemented by adding a permissions check function to the new channel addition workflow in the dashboard. This function would query the channel's permissions for the bot and compare them to the necessary permissions. If the permissions are not correctly set, the function would trigger an alert with instructions for the user.

Sanitize guild_id in HTTP responses to prevent potential XSS attacks

In the current implementation of ServerQuery, the guild_id is included directly in HTTP responses without being sanitized first. While guild_id is provided by the Discord API and not user-inputted, it is included in URLs and could potentially be manipulated.

This could pose a potential risk for Cross-Site Scripting (XSS) attacks, where an attacker tricks a user into clicking a malicious link that includes a script in the guild_id.

To resolve this issue, we need to sanitize guild_id before including it in HTTP responses. This can be done using a library such as escape-html or validator.

Steps to Reproduce:

Make a GET request to the /api/get/bot/:guild_id/servers endpoint with an invalid guild_id.
Observe the HTTP response. (in this case it seems that the guild_id is being sanitized and converted to a string, but to be doubly sure, I want to add sanitization to all endpoint variables, just in case)

Expected Outcome:
The guild_id in the HTTP response should be sanitized and not pose any risk for XSS attacks.

Actual Outcome:
The guild_id is included directly in the HTTP response without being sanitized, potentially posing a risk for XSS attacks.

Suggested Fix:
Use a library like escape-html to sanitize guild_id before including it in HTTP responses.

Relevant Example Code Snippet:
See getRoutes.js

router.get('/:guild_id/servers', function(req, res) {
    const { guild_id } = req.params;
    // ...
    res.status(404).send(`No servers found for guild ID: ${guild_id}`);
    // ...
});

https://github.com/ihasTaco/ServerQuery/security/code-scanning/37

Trend Line on Graph Starts from Left Instead of Right

In the current implementation of ServerQuery, the trend line on the graph starts from the left side and moves towards the right. This behavior contradicts the expected flow of time, as newer data points should appear on the right side of the graph, causing the line to move from right to left.

This issue might cause confusion among users, as they might interpret the graph as displaying data in reverse chronological order.

We need to adjust the graph generation logic to ensure the trend line starts from the right side of the graph, representing the most recent data, and moves to the left as new data points are added.

Steps to Reproduce:

Start the ServerQuery bot and let it generate a graph. (This will take at least a day to fully fill the graph and make the trend line to start filling with data)
Observe the direction of the trend line on the graph.

Expected Outcome:
The trend line should start from the right side of the graph and move left as new data points are added, representing the flow of time correctly.

Actual Outcome:
The trend line starts from the left side of the graph and moves to the right, which could lead to misinterpretation of the graph data.

Possible Solution
During development, the 'Player Amount' line exhibited similar behavior. The solution was to pad the 'Players' variable with zeroes until it was completely populated. Applying the same technique to the 'trend_data' should resolve this issue. Importantly, this change will not affect the server_info.json file, as the adjustment is made within the graph script itself and is not written to the JSON file.

Investigate Potential Prototype Pollution Risk in Server Deletion Endpoint

In the current implementation of the server deletion endpoint (/delete-server), the delete operation is used with potentially user-provided guild_id and server_uuid values. Although these values are retrieved from req.body and are not directly user-controlled, there is a theoretical risk of prototype pollution if they were manipulated by an attacker.

Prototype pollution is a type of vulnerability where an attacker can modify the prototype of a JavaScript object, potentially causing unexpected behavior in the application.

Steps to Reproduce:

This is a theoretical vulnerability and does not have specific reproduction steps in the current implementation.

Expected Outcome:

The application should not allow prototype pollution via user-provided guild_id and server_uuid values.

Actual Outcome:

The current implementation does not present a clear risk of prototype pollution, but further investigation and potential mitigation measures are warranted.

Suggested Fix:

Add input validation to ensure that guild_id and server_uuid are in the expected format before they are used. For example, if these IDs should only contain alphanumeric characters, reject any values that contain other characters.

Relevant Code Snippet:

See delete-server endpoint

router.delete('/delete-server', async (req, res) => {
    const { guild_id, server_uuid } = req.body;

    // ...

    // Delete server_uuid
    if (serverInfoData[guild_id]) {
        delete serverInfoData[guild_id][server_uuid];
    }

    // ...
});

Bot Fails to Update Guild List When a New Guild is Added

The ServerQuery bot is currently experiencing an issue where it fails to update its guild list when a new guild is added. As a result, the bot does not recognize the new guild and cannot interact with it as expected.

This issue can lead to a lack of functionality for new guilds and can hamper the bot's ability to scale with growing user activity.

We need to investigate why the bot does not update its guild list and implement a fix to ensure that all new guilds are recognized and handled appropriately by the bot.

Steps to Reproduce:

Add a new guild to the bot.
Check the bot's guild list.

Expected Outcome:

The bot's guild list should update to include the new guild.

Actual Outcome:

The bot does not update its guild list when a new guild is added, and the new guild is not recognized by the bot.

Possible Solution:

This issue might be addressed by triggering a guild list update whenever a new guild is added. This would ensure that the bot's guild list is always up-to-date and that all guilds are recognized by the bot. However, the root cause of the issue needs to be identified to determine the most effective solution.

Implement Rate Limiting to Prevent Potential DoS Attacks

In order to safeguard ServerQuery against potential Denial-of-Service (DoS) attacks, we need to implement rate limiting on all POST requests. Rate limiting will ensure that our server doesn't get overwhelmed by a large number of requests within a short timeframe, preserving the reliability and availability of our service.

We are currently considering using the express-rate-limit package for this task, but we are open to other suggestions.

This issue encompasses the following security alerts:

Tracking issue for:

ihastaco / serverquery Goto Github PK

serverquery's People

Contributors

Watchers

serverquery's Issues

Bot Occasionally Fails to Update Embeds

Bot stopped updating embeds completely

Sharding Worker Keeps Closing - Unhandled Promise Rejection

Add Error Handling to Prevent Server Crashes

Trend Line Data Does Not Affect Graph Height

Dashboard Check for Channel Permissions When Adding a New Channel

Sanitize guild_id in HTTP responses to prevent potential XSS attacks

Trend Line on Graph Starts from Left Instead of Right

Investigate Potential Prototype Pollution Risk in Server Deletion Endpoint

Bot Fails to Update Guild List When a New Guild is Added

Implement Rate Limiting to Prevent Potential DoS Attacks

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent