ihastaco / serverquery Goto Github PK
View Code? Open in Web Editor NEWA Discord Bot that queries game servers
License: Mozilla Public License 2.0
A Discord Bot that queries game servers
License: Mozilla Public License 2.0
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:
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.
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
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:
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.
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:
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.' });
});
});
});
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:
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.
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:
Benefits:
Implementing this feature would provide several benefits:
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.
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:
/api/get/bot/:guild_id/servers
endpoint with an invalid guild_id.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}`);
// ...
});
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:
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.
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:
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];
}
// ...
});
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:
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.
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.