3.8 KiB
BantFlags
A user script and backend enabling user created flags on bant, originally based on extraflags.
Userscript
The userscript takes advantage of GM_xmlhttpRequest
to get and set flags with
the backend. A user's flags are stored between pages using GM_setValue
and
GM_getValue
.
Old versions of GreaseMonkey will be able to recieve updates to the
script through use of the @updateURL
and @downloadURL
directives,
though these were depricated sometime in GreaseMonkey 3.x and updates
are only checked from the location the script was downloaded from so
be careful where you upload links.
On self hosting, changing back_end
to your domain should be all
you need to do, but don't take this as fact.
The userscript has been designed specifically to target ECMAScript 2015 (ES6), making liberal use of arrow functions, and const/let declarations. Update your hecking browser.
Backend
Prerequisites
- .NET core 3.1
- Mariadb / mysql
.NET dependancies
- Nito.AsyncEX
- Newtonsoft.Json
- MySql.Data
- Microsoft.AspNetCore.Mvc.NewtonsoftJson
- Microsoft.AspNetCore.StaticFiles
- Microsoft.EntityFrameworkCore.SqlServer
- Microsoft.EntityFrameworkCore.Tools
Setup
- Install .NET
- Clone and build the BantFlags .NET project.
-
Create the database using
database.sql
.- Change the password.
-
configure
BantFlags/appsettings.example.json
with your connection string and webroot (the directory you wish to serve the flags from) and rename it toappsettings.json
- The location of the BantFlags application and the served content
are not necessarly the same. If you leave it empty, or provide a
nonexistant path the application will look for the
wwwroot
folder inside the working directory. - This should be placed either in inside the working directory or the same directory as the program.
- The location of the BantFlags application and the served content
are not necessarly the same. If you leave it empty, or provide a
nonexistant path the application will look for the
- Add flags to the backend (currently only possible by querying the
database directly), and place image with the same name in
{webroot}/flags/
. -
Configure your webserver of choice to forward requests to kestral
- Example nginx config.
- Run the application
- ???
- profit.
Database
Tables look like this: posts
id | post_nr | board |
1 | 12345 | bant |
2 | 56789 | bant |
flags
id | flag |
1 | patchouli |
2 | chen |
postflags
id | post_nr | flag |
1 | 1 | 1 |
2 | 1 | 2 |
2 | 2 | 2 |
where post_nr and flag in postflags are the id fields in their respective tables.
extraflags stores all of a post's flags in one table as a varchar, seperated by "||", which is split and joined by the script when getting and posting respectively. This is extraordinarily inefficient, but for their purposes it's not such a glaring issue (the highest amount of flags I've seen is 6). One aim of this rewrite is to greatly increase the amount of flags usable at once, and this database structure allows the maximum to be arbitrarily high.
API
The backend exposes three endpoints used by the userscript to get and post flags, and a flags directory storing the images themselves.
route | purpse |
---|---|
/api/get | Get flags using post numbers in the thread |
/api/post | Add flags to the database |
/api/flags | List the flags we support |
/flags/* | The flag images |
Backwards Compatibility
The API is 1:1 compatable with all previous versions of bantflags,
but also encodes a new version
variable when getting flags which
allows for breaking changes in the script while the backend only
sends data it knows is parsable.