Web Server API

[yangm97]

Continuing what we started here.

I think the Cuberite binary should have a simple web server, maybe moving webadmin to a plugin, thus allowing any plugin to display webpages on it's own namespace. ie. cuberiteserver.com/webadmin for the webadmin plugin, cuberiteserver.com/dynmap for dynmap, etc. I guess this would be more resource efficient then each plugin running it's own webserver, and as such, only a single port would be mapped, as opposed to each plugin's web server running on a different port. 

This is not meant to deprecate the current webadmin API. And moving webadmin into a plugin should be considered as it's own thing. The main discussion here is how and should add a /namespace for plugins, outside of webadmin namespace.

[NiLSPACE]

Just to be clear, the current webadmin does exactly what you requested here. Every plugin has it's own space with the tabs (For instance gallery.xoft.cs:<port>/webadmin/Core/Chat), so the question pretty much is: Do we want the webadmin integrated in Cuberite or should we move it inside a plugin.

I'm personally inclined to keep it integrated, but I would like to see some changes. For example, I'd like to be able to limit a webadmin user to specific tabs and for plugins to be able to change the return HTTP status code and returned headers. lastly I'd like to be able to hide webtabs from admins as they most likely do not want to see tabs that provide an API. We could possibly add a new method cWebAdmin:AddAPI which would do that. We could even change the API requests to something like "gallery.xoft.cs:<port>/webapi/Core/Chat"

[yangm97]

Plugins currently live under the webadmin namespace, and require authentication to be accessed.
Even if we had the ability to have multiple permission groups under web admin, that would still make plugins live under /webadmin namespace, as if they were second class citizens. Also I don't think hosting a public map under /webadmin/dynmap makes sense at all. Guests aren't administrators, they shouldn't be able to reach things labeled as such.
Maybe  renaming the current webadmin api to just web api, dropping the /webadmin namespace and add admin features as a plugin (which would be accessible at /webadmin) alongside a revamped permission/login system would tick all the boxes?

[xoft]

The first problem you ever run into when designing a system with both public and private faces is, how do you manage accounts? Webadmin was designed as a simple way for the admins to manage the server, it is simple - the main server admin defines the accounts in the webadmin.ini file. But if there are to be accounts and permissions and what not, who then creates the accounts? Who assigns all the permissions? Does Cuberite store the logins? Or do we use a third party for logging in?

I wouldn't remove the current system, it work okay for what it was meant. We could simply add another system outside of the "/webadmin" namespace, with any rules we think of. That way, we can simply phase webadmin out slowly, after all the plugins are migrated to the new system.

I definitely don't like webadmin-as-separate-plugin. Too much setup and maintenance cost, with nearly zero advantages.

[yangm97]

I don't think there's an urge to get rid of the webadmin. It serves its purpose as an administration tool (except when it gets on the way of adopting YAML as standard config files).
It also doesn't need to be fully rewritten as a "real" plugin, I think it can live as a "special snow flake" just fine. It would look and act as a plugin anyway still.
As for logins, permissions and such, it could be done this way: settings.ini holds the "root" account (could still be called admin), additional users would be identified by their in-game nicknames, credentials would then be handled by something like the Login plugin, permissions would be handled by the Core permissions system.
Without these plugins everyone would be considered a guest (unlogged in group) user unless they have the root password. So permissions and account management are completely optional.

Looks work-able for me, and mostly not over the top.

[ShadowCone]

I don't see why we should abolish the webadmin, but I would like to see an interface for plugins to publish sites that are publicly available without authentication (and an interface for dynamic pages made by a lua callback function)

For example, I want to build a matrix cuberite chat bridge but matrix works over http so I need to run my own webserver to communicate with the matrix server whereas I would need basically a lua function exposed via http (as an api)

[yangm97]

This way, some features asked here wouldn't need to be implemented into webadmin anymore. Webadmin could take a KISS approach without restricting developers to the building blocks provided by webadmin or any framework it adopts because they would have access to a full webserver instead, loading any assets they desire.

I guess the webadmin maintenance "costs" would go down while customizability would go up.

offtopic: why so many git branches?

[ShadowCone]

Mostly do agree.

Offtopic: the core team doesn't develop in forks, but they use the original repo and create branches. There are some branches that were abandoned, there are some that are actively developed and there are some that are somehow struck and isn't used so much....

[sphinxc0re]

I think a cWebServer singelton object that plugins can use to mount their own http data handler would be a very good idea. Although we would have to implement some interface to make plugins have their own plugins. The webadmin currently has a lot of plugins that register panels on it

[sphinxc0re]

It would most likely look like this:

-- handler.lua

StaticFileHandler = {}
StaticFileHandler.__index = StaticFileHandler

function StaticFileHandler.new(folder)
   local this = {}
   setmetatable(this, StaticFileHandler)
   this.folder = folder
   return this
end

function StaticFileHandler:handle_request(request)
  -- something to handle the request
  return response
end


-- main.lua

cWebServer:get().mount(StaticFileHandler.new("./public/")).onto("/")