Naleksuh wrote: ↑Sat Aug 07, 2021 10:44 am
Hmm, which are you saying are the "duplicated arguments"? If you mean the email and password, this is because while most APIs requires a login step, NFOservers.com does not due to transmitting the password directly (this practice was questioned in
viewtopic.php?t=15937 but it helps when making a library) - in most libraries you have to do a login step first then hold onto that, but with NFoservers.com it's a lot easier to use because you can do just about any action you want in a single request, by transmitting the username and password, which is why it's set up like that. It might however, make sense to have objects for holding onto specific services, which would probably also include the authentication needed to use them.
If that's not what you were talking about, what other ones are there?
Sorry for the confusion here. I'm referring to those in this case and am indeed aware of how our internal systems work in regards to the username/password utilization. I wrote something similar to this years ago, once in PHP, once in Java, then a third time in node for some staff tools we use.
What I am saying is that you could break them out into vars inside a class object. It would just reduce the number of arguments to the functions in this case, which can sometimes lead to cleaner code. Perhaps I should have included an example initially.
I will show a version of your code converted to a class to illustrate what I'm talking about, hopefully this makes what I was saying more clear. I also added some generics to it just for example purposes.
Code: Select all
const fetch = require('node-fetch');
class NFO {
constructor(email,password,service,servicetype) {
this.email = email;
this.password = password;
this.service = service;
this.servicetype = servicetype;
}
ChangeServiceAndType(service,servicetype) {
this.service = service;
this.serviceType = serviceType;
}
POST(controlpage, posttype) {
fetch("https://www.nfoservers.com/control/" + controlpage, {
"headers": {
"Content-Type": "application/x-www-form-urlencoded",
"Cookie": "email=" + this.email + ";password=" + this.password + ";cookietoken=a"
},
"body": "cookietoken=a&name=" + this.service + "&typeofserver=" + this.servicetype + "&" + posttype,
"method": "POST"
}).then(console.log);
}
Restart() {
switch(this.servicetype) {
case "game":
this.RestartGame(this.service);
break;
case "virtual":
this.RestartVDS(this.service);
}
}
Stop() {
switch(this.servicetype) {
case "game":
this.StopGame(this.service);
case "virtual":
this.SoftShutDownVDS(this.service);
}
}
Start() {
switch(this.servicetype) {
case "game":
this.StartGame(this.service);
break;
case "virtual":
this.StartVDS(this.service);
}
}
StartGame() {
this.POST("control.pl", "do_it_submitted=1&selection=start");
}
StopGame() {
this.POST("control.pl", "do_it_submitted=1&selection=stop");
}
RestartGame() {
this.POST("control.pl", "do_it_submitted=1&selection=restart");
}
ShutDownVDS(){
this.POST("virtcontrol.pl", "power=off");
}
SoftShutDownVDS(){
this.POST("virtcontrol.pl", "power=softoff");
}
StartVDS(){
this.POST("virtcontrol.pl", "power=on");
}
RestartVDS(){
this.POST("virtcontrol.pl", "power=softoff_then_off_then_on");
}
ReinstallVDS(newos){
this.POST("virtcontrol.pl", "install=" + newos + "&install_confirm=1");
}
ChangeVNCPassword(){
this.POST("virtserveraccess.pl", "changevnc=Change+VNC+password");
}
}
//Example using new class and generics
let myService = new NFO("email@example.com","password","myVDSIdentifier","virtual");
myService.Stop();
myService.ChangeServiceAndType("differentVDSIdentifier",virtual);
myService.Stop();
I am a big fan of generics and reducing passing variables around where possible, just to make it easier for someone trying to implement a class later, I also prefer not add a bunch of functions to the global namespace where possible, hence the NFO class.
Vortire wrote: ↑Sat Aug 07, 2021 11:19 am
Ah the joys of Node aha. The exact reason I refrain from it
Also Cody please could you push for hashed passwords, please
I know all connections are SSL and cryptographically secure but theres just something about seeing a plaintext password in a cookie that unsettles me.
Node isn't the worst, but I'd prefer stick with Java if I could. But I'm stubborn like that.
It is on the todo list, but as part of a significantly wider scope than this. The entire authentication system needs reworking to allow for us to do cool things, such as an official API.
I imagine both you and Naleksuh have been looking at ways to
read from the panel and have already worked out the pain that will be involved there.