|
Sourcebans 3 - Community project, help wanted!
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: HTML Code:
if(hasPermission(['admins.delete', 'servers.*']))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 |
Re: Sourcebans 3 - Community project, help wanted!
Nice.
|
Re: Sourcebans 3 - Community project, help wanted!
Ohh that sounds nice, some different themes on the website side would be handy if someone does do anything with that part.
|
Re: Sourcebans 3 - Community project, help wanted!
Wow looks really good!
|
Re: Sourcebans 3 - Community project, help wanted!
Good luck with this, nice project.
Quote:
That would also slow down querying. Quote:
My very personnal opinion btw, I'd love to discuss that. |
Re: Sourcebans 3 - Community project, help wanted!
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. |
Re: Sourcebans 3 - Community project, help wanted!
Quote:
I personally don't think there's any real complexity involved there. Quote:
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. Quote:
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. |
Re: Sourcebans 3 - Community project, help wanted!
Nice, but no preview for ban entry/list or server info/list?
|
Re: Sourcebans 3 - Community project, help wanted!
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 |
Re: Sourcebans 3 - Community project, help wanted!
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. |
| All times are GMT -4. The time now is 06:21. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.