Add a way to prevent the users from spamming the appeals

[OviiiOne]

A banned user can create several appeals and flood the channel, which is something I rather not see

[sylveon]

That's something I've also thought of when initially designing this, unfortunately it might bring this into the paid realm (I really want to keep this hostable 100% free). The closest is Netlify Identity (#2) to create an Identity for the user (1k identities per site max, $99/month when exceeded), or moving to AWS so that I can use DynamoDB (which is pay for what you use, so cheaper for most use cases, but vastly more complex for the average user to setup).

Another alternative is reading back the channel's content: it doesn't prevent all instances of duplicate ban appeals, but should prevent basic flooding (as long as the attacker isn't using more than 50 banned accounts, eg as part of a raid).

[OviiiOne]

I see...

[jcsumlin]

Had a few ideas here... Maybe add support for the Netlify CMS to be able to maintain a blacklist of ids stored in a json file of the forked repo. Then each time someone auths themselves on the appeal front end it checks their user id against that file.

[hazre]

Any update on this?

[NoodlesDev987]

There should be blacklist for appeals, that you can specify user ids separated by , in .env that wont be able to submit appeal

[jcsumlin]

There should be blacklist for appeals, that you can specify user ids separated by , in .env that wont be able to submit appeal

This could also work with the current infrastructure stack. I may open a PR for this feature later today

[sylveon]

I'm a bit low on time recently so that would be very much appreciated 😊

[NoodlesDev987]

I have better idea: Add link to reject appeal to embed, when staff clicks on it, ID of appeal submitter should be written to json file. When this user is trying to submit new appeal and their ID is in json file, error message should be displayed that user's appeal was rejected.

[OviiiOne]

Hmmm... I personally like to give the users several opportunities, rejecting an appeal shouldn't prevent the user from appealing in the future.

[jcsumlin]

I personally like to give the users several opportunities, rejecting an appeal shouldn't prevent the user from appealing in the future.

Adding a reject option that DMS the user saying their appeal was rejected may be a good idea

[NoodlesDev987]

Hmmm... I personally like to give the users several opportunities, rejecting an appeal shouldn't prevent the user from appealing in the future.

So the feature should be called block user from sending new appeals

[NoodlesDev987]

Adding a reject option that DMS the user saying their appeal was rejected may be a good idea

Dming user when the user does not have shared guilds with bot is not possible

[NoodlesDev987]

And the idea I suggested is to block the user from sending appeals.

And maybe there should be added to create webhook using oauth in server and channel that the user can choose. This would be for replying to user's appeal, when staff clicks on approve link, message should be sent to the webhook to let the user know that the appeal was approved. Message should be sent to webhook also when staff clicks on reject appeal and also for block the user option

Hope you will like my idea and it will be implemented 😃

[OviiiOne]

Guess this is solved then, as there is now a way to block users ( #30 ).

Ideally, I would've liked an autoblock feature that prevents new appeals from a user until their appeal is reviewed, but this will do.