[Oo Alias oO]

Since development of Sourcebans 2 is dead, and 1.4 is an old version which could do with a fresh face and newer features, I decided to start on the project myself as Sourcebans 3.

This has some updated features such as Steam Login & responsive design. I also plan on serving a JSON API to the plugin which connects via HTTP requests, which would be more secure and stop raw queries being directed at the database.

Currently the development is on-going by myself, using Laravel 5 and MySQL. The front-end is currently basic Bootstrap 3. Below are the features, and screenshots of the current progress:

https://github.com/sourcetools/sourcebans

Installer

Private details (database, SMTP) are stored within an untracked .env file. A global screen will appear if a database connection cannot be established with these details.

With correct details, an installer screen is shown, allowing a user to login, set the application settings and proceed to migrate the database tables with seed data.

This is complete, however needs an application key check adding.

Steam Login

In order to add reports/appeals you must login via Steam. If you are added as an Admin, when you login you'll have access to the Admin backend.

This is complete.

Web/Server/Command Groups

Web: Add groups, by selecting certain permissions (adding admins, editing servers etc).
Server: Add groups, by selecting certain flags.
Command: Command groups allow custom commands to be created in groups, and then the groups assigned to flags.

This is complete, but may need some tweaks.

Web Permissions

This works by checking a users web groups. A global "hasPermission" function allows for easy backend and view authentication:

if(hasPermission(['admins.delete', 'servers.*']))

This would return a boolean if the user is allowed to either delete admins, or perform any server actions.

This is complete.

Servers

Servers can be added, as long as there is a correct IP, Port and RCON password. Server details are loaded into Cache, or information is checked with the Steam API if not in cache.

This is complete.

Settings

Update the application settings.

This is complete.

API

The plugin will communicate over a HTTP API towards the website. A key (in settings) is required to be passed through as a header value.

Only the middleware check is complete.

---

Quite a bit has been done, however there is still loads left to do. If anyone is interested in helping give me a shout.

I don't have any experience with the plugin development, so looking for some assistance there.

Overall this would be a way more flexible and up-to-date website & plugin, which just needs some community help!

Cheers!

Steam: aliasell

Screenshots: https://www.dropbox.com/sh/evhpo1jpd...5T99CHJ-a?dl=0

[Sarabveer]

Nice.

[Horsedick]

Ohh that sounds nice, some different themes on the website side would be handy if someone does do anything with that part.

[TUSK3N1337]

Wow looks really good!

[JoB2C]

Good luck with this, nice project.

I also plan on serving a JSON API to the plugin which connects via HTTP requests, which would be more secure

I do not agree with that. I cannot see how this could increase (or even not decrease) the security at all.

That would also slow down querying.

and stop raw queries being directed at the database

Uhm... This makes no sense. What is that supposed to mean?


My very personnal opinion btw, I'd love to discuss that.

[Oo Alias oO]

Thanks

Well the main reason I wanted to do an API is due to database relationships. There's quite a few complex relationships involved and having to work these out with SQL can cause issues... For example the N+1 issue could easily come into play. This obviously is easily avoided using an API.

Security wise, you don't pass any database credentials into the plugin at all, just a easily changeable API key and URL. To me, that's more secure.

As for slowing down querying, I don't see why? If anything, the queries will be more optimised, only returning the exact data needed.

[JoB2C]

Originally Posted by Oo Alias oO There's quite a few complex relationships involved and having to work these out with SQL can cause issues... For example the N+1 issue could easily come into play. This obviously is easily avoided using an API.

You know, you can do a JOIN by yourself in your plugin or whatever else MySQL offers. Those problems are not in any way related to SourcePawn or PHP, but more to the developer that write the queries. (PEBKAC :p)

I personally don't think there's any real complexity involved there.

Security wise, you don't pass any database credentials into the plugin at all, just a easily changeable API key and URL. To me, that's more secure.

Without access to your filesystem, there is no way anyone can read your databases.cfg file. With your system, the same applies (access config, get access). Plus passing a password (yes, a password) as a HTTP header value is in general not a good idea.

How could that be more secure when you add things that can grant access? It's like having two keys that open the same door, it can't be better (in terms of security) than having only one.

As for slowing down querying, I don't see why? If anything, the queries will be more optimised, only returning the exact data needed.

Plugin -> Database -> Plugin
Plugin -> HTTP -> Database -> HTTP -> Plugin

You're adding parts to the process, it's kinda obvious that it can't be faster.

I assume you'll be using an ORM to manage your queries, and they are not made to be fast but simple to use. So, for the small complexity of the queries that will be issued by the plugin, you're adding an extra layer that is slow and useless from my point of view.

If you're not gonna use an ORM, you're writing the queries yourself. In this case, you're adding an extra layer for absolutely nothing you can't do in the plugin.

[Bara]

Nice, but no preview for ban entry/list or server info/list?

[WildCard65]

I have to go with NOT using a json api for the SM plugin on the account that sourcebans I believe should be independent of 3rd party extensions, your current plan would make users have to install SMJansson + either 2 extensions: CURL or SteamWorks.
The original sourcebans only required the MySQL extension which is STOCK of SM.
On the otherhand, the JSON api would be useful for community webpages + forum plugins.

In conclusion: I say do keep the JSON api, But don't make the sourcebans SM plugin require that api especially since it'll cause more overhead then interacting straight with the database would create

[psychonic]

Having a single (web) API for everything to go through is far more sane imo. The whole purpose of the SM extension API is for third-party extensions to be able to exist.

Refusing to use them is silly and not a good reason to not have a unified API to the project.