Login

[NiLSPACE]

The first version is online: https://github.com/NiLSPACE/Login/tree/networkapi

By default the API is disabled. To enable go to you configuration file and change/add the NetworkAPI.Enabled to true. (Like this, but then Enabled = true
You'll have to come up with some sort of client secret that is at least 10 characters long to prevent misuse of the API. You can also change the port of the API if you want.

To call the API you send JSON to it. The JSON looks like this:

Code:

{
  action: 'APIAction', // Currently only RegisterUser is available.
  playername: 'myplayername', // The name of the player to register
  password: 'MyPassword', // The password that you want the user to have
}

In PHP it looks somewhat like this:

PHP Code:

function JsonRequest($url, $secret, $data) {
 $ch = curl_init($url);
 curl_setopt_array($ch, [
 CURLOPT_POST => true,
 CURLOPT_RETURNTRANSFER => true,
 CURLOPT_HTTPHEADER => [
 'Authorization: ' . $secret,
 'Content-Type: application/json',
 ],
 CURLOPT_POSTFIELDS => json_encode($data)
 ]);

 $response = curl_exec($ch);

 return $response;
}


 JsonRequest("localhost:8888", "VerySecretPassword", [
 'action' => 'RegisterUser',
 'playername' => 'TestUser',
 'password' => 'password'
]); 


The API also returns JSON which looks like this:

Code:

{
    "msg" : "The user is already registered",
    "result" : "failed"
}

It only returns anything if everything was okay though. I still have to make it return something if something went wrong.

[yangm97]

[*] Storage: This can be "sqlite" (default). If choosen for sqlite the plugin will save everything in an sqlite database.

Does that mean other database will be supported too, like postgresql and mysql?

[NiLSPACE]

It's possible, but they're not supported at the moment.

[ShadowCone]

I know it's a bit older, but is it possible to give cuberite itself a bit broader api so cuberite is the Webserver and a plugin can register a public available page (like /api/something) and specify a callback that is used for page generation similar to such callbacks that are used in nodejs (express or http modules). It would simplify a lot I think

[NiLSPACE]

While it's not possible to register a public available page, you can register a page using cWebAdmin:AddWebTab. If the http request provides the proper Authentication header you should be able to call it. The Authentication header is filled with the type of authentication (in our case 'Basic') with "<Username>:<Password>" in base64 after it. An account called 'Test' with a password 'Test' would have a header like this: "Authentication: Basic VGVzdDpUZXN0".

It would be pretty cool if we could limit webadmin accounts to specific web tabs. That way we can add accounts that can specifically call such API pages. If we're going with this route we should also make it possible to hide tabs in the webadmin itself, since an admin doesn't want to see an API page. We should also make it possible to change the HTTP status code and headers, but that isn't too hard to do. We just add a second or even third return value or something.

@xoft, any thoughts if this is feasible?

[yangm97]

I would say the webadmin should be a plugin itself, then Cuberite would allow plugins to serve pages anyway they want: public facing page at hostname:8080/pluginname? Sure! Plugging into a login and a permissions system to allow specific groups? That's fine too! And then the webadmin should be for... admins. Plugins should still be able to plug into webadmin for... administration stuff.
This would workaround the fact spigot plugins can start their own webservers on whatever port they so desire.

[NiLSPACE]

You do realize that you can simply change the port in the webadmin.ini file right? We also already have different users. For instance, on the gallery server I have a webadmin account, and xoft has his own. If we could simply expand the current user system to allow people to set permissions together with what I proposed earlier you'd have a pretty powerful API framework.

I'm personally not a fan of moving the webadmin to a plugin as too many plugin currently rely on the way it's done now. Plugins can already create their own webservers. Here is one I wrote right after the cNetwork API was implemented.

[yangm97]

You do realize that you can simply change the port in the webadmin.ini file right? We also already have different users. For instance, on the gallery server I have a webadmin account, and xoft has his own. If we could simply expand the current user system to allow people to set permissions together with what I proposed earlier you'd have a pretty powerful API framework.

I'm personally not a fan of moving the webadmin to a plugin as too many plugin currently rely on the way it's done now. Plugins can already create their own webservers. Here is one I wrote right after the cNetwork API was implemented.

Changing the port is not the point, I meant to say a plugin like dynmap can host its public web interface at :8123 while some other plugin uses another port. What I proposed was having a single webserver which plugins would plug into and have their own /namespace/, as opposed to each plugin running their own webserver and each one using a different port.

[NiLSPACE]

Dynmap could perfectly work within the webadmin. Anyway, We're going way off track here. Can you make a post in another forum? Perhaps linking to the post here that started the discussion?

[yangm97]

Agreed. Here it is: https://forum.cuberite.org/thread-2632.html