norrisng / fcomserver Goto Github PK

When a user attempts to use the register bot command on a publicly-visible channel, mention the user and tell them to PM instead.

Allow users to specify a blacklist for forwarded messages.

That is, a user should be able to specify callsigns from which they don't want messages to be forwarded.

This blacklist of callsigns should be defined by the user via the Discord bot.

When storing user-entered callsigns (i.e. the first thing that gets entered when the client is opened), auto-capitalize them before saving them to the database.

Ultimately, it doesn't really matter that much, as its only use is to serve as a "confirmation" for the user. It merely provides a way for a user to make sure that their verification code hasn't been used by someone else (via the status bot command).

That being said, it does look nicer.

Currently, all logging info is continuously written to 2 files (one for the bot, and one for the API).

Maintain the separation between bot and API log files, but switch to rotating logs so that a new file (one for the bot, and one for the API) is created every day.

This also makes it easier to archive them.

Reference: https://www.blog.pythonlibrary.org/2014/02/11/python-how-to-create-rotating-logs/

Whenever a on_message(message) event is triggered, and the message object provided doesn't belong to a DMChannel (e.g. belonging to a TextChannel instead), the forward_messages() loop crashes. Incoming messages (from the API) will continue to pile up in the DB queue. However, bot commands (i.e. register/status/remove) will continue to work.

Restarting the bot will temporarily solve the issue until a non-DMChannel message is once again presented to the bot.

There appears to be a memory leak with the bot, as restarting it will release some RAM. The cause of the memory leak is unknown.

The bot was manually restarted after 14 days (Oct 20 - Nov 2), releasing 91.1 MB of memory. Of note, however, is that CTP happened during the beginning of this window, and that FCOM has seen the highest level of activity this event. However, it's still far from what would be expected for widespread use.

Unconfirmed registrations persist in the database, even after 24 hours (which is when confirmed registrations are supposed to be deleted).

When a registered user (confirmed or otherwise) sends remove to the bot, their registration entry is removed, but the bot does not reply with a message acknowledging removal (as is expected).

However, this does not occur if the user is not registered.

As title. This seems to be because the bot doesn't ignore messages from itself (bot/discord_bot.py).

See https://github.com/Rapptz/discord.py/blob/rewrite/examples/reply.py

Download/parse data from the data feeds for IVAO and VATSIM, allowing for richer functionality:

• IVAO (via Whazzup): https://www.ivao.aero/whazzup/status.txt (under url0/gzurl0)
  • 3-minute (unenforced) refresh rate
  • Must prefer gzipped version (gzurl0)
• VATSIM (via the VATEUD API): http://api.vateud.net/
  • 2-minute refresh rate

In the case of IVAO, all data will have to be downloaded/unzipped/parsed, due to the lack of granularity in Whazzup.

Text messages sent over frequency are not parsed into a friendly format as intended (e.g. "122.800 MHz"). Instead, they're simply displayed as the original 6-digit number encoded by the FSD server (e.g. "122800").

It appears that VATSIM encodes frequencies differently compared to IVAO. The existing code assumes that VATSIM uses the same format as IVAO (see below):
* VATSIM: xxxyyy for xxx.yyy MHz
* IVAO: @xxyyy for 1xx.yyy MHz

Warn the user if they are using an outdated client version.

This information is contained inside the user agent string of client requests, starting with version 0.8.0 (FcomClient/0.8.0). All builds prior to this will instead provide the default RestSharp user agent (RestSharp/106.3.1.0)

Currently, verification codes can contain other characters, as long as they're URL-safe.

Instead, generate verification codes that only have alphanumeric characters. This makes it easier to simply double-click to highlight the entire code in Discord.

Credit: bantha121

SQLite is used currently. Migrating to MariaDB will allow for concurrent access.

The following things will need to be changed to reflect this:

• Schema (e.g. changing to bool, varchar)
• Database connections in db_manager.py

Also, stop using autoincrement, and use message timestamps for ordering instead. There may be a need to write a DB trigger for insert time, so that clients can't manipulate message queue priority.

Quick reference: https://mariadb.com/resources/blog/how-connect-python-programs-mariadb

After the Discord outage on 2019-01-12 at 1050z, the bot failed to forward any messages, even after Discord was back up and running.

In this case, the server threw a HTTP 500 error:

Task exception was never retrieved
future: <Task finished coro=<forward_messages() done, defined at .../FcomServer/bot/discord_bot.py:17> exception=HTTPException('INTERNAL SERVER ERROR (status code: 500): 500: Internal Server Error',)>
Traceback (most recent call last):
  File ".../FcomServer/bot/discord_bot.py", line 44, in forward_messages
    await dm_channel.send(dm_contents)
  File ".../FcomServer/venv/lib/python3.6/site-packages/discord/abc.py", line 764, in send
    data = yield from state.http.send_message(channel.id, content, tts=tts, embed=embed, nonce=nonce)
  File ".../FcomServer/venv/lib/python3.6/site-packages/discord/http.py", line 221, in request
    raise HTTPException(r, data)
discord.errors.HTTPException: INTERNAL SERVER ERROR (status code: 500): 500: Internal Server Error

Currently, registration and message forwarding events will fail if the database is locked.

Instead, it should re-attempt the database operation some number of times. Probably not a good idea to reattempt an infinite number of times, so that the client isn't stuck waiting.

Implement a broadcast command for the admin. This would allow online users to be notified in the event of a scheduled server shutdown.

When a registration is confirmed by the client, send a message to the user over Discord.

This can be implemented by having the API additionally insert a message into the messages table whenever the registration endpoint is called.