feat: Add PSUControl eWeLink plugin

[chrismin13]

• You have read the "Registering a new Plugin" guide.
• You want to and are able to maintain the plugin you are registering, long-term.
• You understand why the plugin you are registering works.
• You have read and acknowledge the Code of Conduct.

What is the name of your plugin?

PSUControl eWeLink

What does your plugin do?

It adds an interface to connect IoT devices that use the eWeLink app (such as Sonoff Smart Plugs) using the existing PSU Control plugin.

Where can we find the source code of your plugin?

https://github.com/chrismin13/OctoPrint-PSUControl-eWeLink

Was any kind of genAI (ChatGPT, Copilot etc) involved in creating this plugin?

Yes, a lot. I have read the guide, and I understand that "vibe coded" plugins are not acceptable. So, I understand if this will not be accepted under that premise, but I wanted to make an attempt anyway, and hope you don't mind me doing so.

However, I would like to mention that I do feel confident in my ability to maintain the plugin in case it breaks or if I need to add a small new feature. I have manually gone through everything, made sure it is safe, fully understand how the code works, and I'm confident in what I am submitting.

If you still think this does not fit your submission criteria due to the use of AI, feel free to reject this pull request.

Is your plugin commercial in nature?

No

Does your plugin rely on some cloud services?

Yes, the eWeLink cloud, which is used for the smart switches. The Privacy Policy on the GitHub repo links to their Privacy Policy for more info.

Further notes

The plugin has been tested with a Sonoff Basic R2 and on an up-to-date OctoPi installation. It would be nice to get some more testers if anyone else has any eWeLink devices hooked up to their printers :D

Thank you for your consideration! Let me know if there's anything you would like to see improved.

[jacopotediosi]

Hello @chrismin13,

I briefly reviewed your repository, these are my suggestions from a security standpoint:

• I recommend implementing is_api_protected set to True to restrict your plugin's API usage to authenticated users only.

• I noticed that in your JavaScript code you use the PNotify function several times. OctoPrint currently ships with PNotify version 3, which by default does not perform HTML encoding of notification titles and text. Since you sometimes insert untrusted data into notifications (such as device names obtained from the cloud), to prevent potential XSS vulnerabilities I recommend setting the text_escape and title_escape attributes to true in all PNotify calls, unless you explicitly need to insert HTML code. Alternatively, you can use the ._escape() function from the Lodash library (already imported by OctoPrint) when concatenating data.

I also have some doubts about encrypting and masking passwords in OctoPrint plugins: it seems like security theater to me.
I see no added security value in encrypting the password at rest, nor in masking it in the frontend, given OctoPrint's current threat model (explained below).
On the backend, the security of passwords stored by plugins is delegated to OctoPrint, which stores all configurations in its config.yaml file. If that file were exfiltrated by an attacker, it would inevitably lead to the attacker becoming an OctoPrint admin. At that point, whatever encryption you implement, nothing could prevent the attacker from obtaining the key you used to encrypt your plugin passwords.
On the frontend, password masking is already handled by the browser, which processes the HTML type="password" attribute.
In this scenario, I see password manipulation as adding complexity to the code and consequently increasing the risk of implementation errors. Other major OctoPrint plugins currently store credentials in plaintext. However, if you still want to keep your current implementation, consider that XOR is an insecure encryption mechanism; you should use at least AES or Fernet.

Thank you again for your contribution 😄