WebAdmin API thoughts
#1
Another set of thoughts, this time on the webadmin and its interaction with the plugins. The current state of affair seems rather fragile and not flexible enough.

Current state:
==============
cWebPlugin implements web-related functions / callbacks
cPlugin_NewLua is also an instance of cWebPlugin


What we want:
=============
We want the following functionality:
  • Plugins can add tabs with custom contents to the WebAdmin interface
  • Plugins can handle individual request URLs (ChatPlugin requests only chat messages in XML, etc.)

Proposed solutions:
=============
cWebAdmin has two lists: Tabs and URL handlers. Callbacks for both can be registered. A tab has a name, title and content callback. An URL handler is simply a callback that may or may not provide content for an URL (?)
cWebAdmin parses each request. If it is for a regular WebAdmin page (URL with a specific prefix), it will create a regular WebAdmin interface page, with tabs, and call the specified tab's content callback to provide the content. If it isn't, it calls the URL handlers to provide the response contents. This way, a plugin can even turn MCServer into a webserver, serving e. g. local files (images in WebAdmin! Smile )
cPluginManager bridges to cWebAdmin, providing means for plugins to register for both categories.
ManualBindings provides the binding between cPluginManager and Lua. cWebPlugin is removed. cPlugin and cPlugin_NewLua are removed from the Lua API.
New API functions:
  • cPluginManager:AddWebTab(TabName, TabTitle, ContentFunction)
    • Adds the tab to WebAdmin, ContentFunction will be called each time tab content is requested
    • function ContentFunction(TabName, URL[, params?]) - returns the content
  • cPluginManager:AddWebURLHandler(ContentFunction)
    • Adds the URL handler, ContentFunction will be called each time URL content is requested
    • function ContentFunction(URL[, params?]) - returns the content for the specified URL

Thoughts? Other than it's gonna be a hell to implement Wink
Reply
Thanks given by:
#2
Not just it's going to be a hell to implement, I can literally see a whole new level for DDoS over MCSBig Grin

For example, you're making an open players rank page (based on kills/expirience for basic phallometry). Thus you'll be using an URL Handler, right? So, someone could exploit it and flood server with url requests Smile Not that it's something bad, just saying...

Overall, URLHandler is something magnificent, if treated with love and some lovely surroundings (by which I mean running server's site).
Reply
Thanks given by:
#3
I was planning that the URLHandler would have the same kind of access control as the webadmin - unless you logged in, you wouldn't get a page. It's just a means for plugins to get data out of MCServer without actually having to register a tab - so for example the webchat plugin can request the chat messages in an XML form, or a plugin webpage can request a map of currently loaded chunks as an image etc. But still everything admin-only.
Reply
Thanks given by:
#4
If you plan on adding permissions to the WebAdmin you can also create public pages that require no permissionsBig Grin
Reply
Thanks given by:
#5
Intriguing idea, this public webserver, but I still think we should stick to the main point of WebAdmin being an Admin interface. I was just trying to simplify things for the web developersTongue
Reply
Thanks given by:
#6
True, but the reason that the WebAdmin supports multiple accounts is because I also planned to have permissions for each account, that way you can have moderators do moderator like thingies while the really technical stuff like changing the server port etc. is not available for them.

I'm not saying permissions should be implemented now, but if done right public pages are possible with no extra effort.
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)