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 😄

[chrismin13]

Hello @jacopotediosi, thank you for taking the time to go through my PR, I really appreciate the feedback!

I've implemented both is_api_protected and the fixes for the potential XSS vulnerabilities you mentioned.

As for the password masking, I agree about your point in regards to it being security theater. Perhaps my original way of phrasing it and explaining the implementation was not great. I understand that, at the end of the day, any data stored on the server will be accessible by an attacker, and there's nothing that can be done for that.

I only wanted to make it so that my password was not visible in plain text when going through the config, as it would otherwise be a normal username and password getting stored, and not some kind of API token or other UUID. So, yes, this is not more secure, but if some config file ever ends up in some kind of log, or if a user copy pastes a config somewhere else, it won't be an instant security issue.

EDIT: So, I forgot to clarify, I've updated all of the documentation to make it clear that this is only obfuscation, not encryption, and I've removed any mention of this from the plugin page, as I don't think it should be advertised as a feature.

If you disagree with this, I would be happy to either remove this entirely, and have the password displayed in plaintext in the OctoPrint config file, or implement AES or Fernet as you suggested.

Thanks again for your time! Let me know if you have any other questions or concerns.