Closed thinksilicon closed 2 years ago
Could you update the tests to use the new example please ?
If I'm not totally mistaken the HTTPClient should handle redirects (http and https) out of the box, so that would close #13 ... didn't test it though.
And with the switch to HTTPClient you could also super easily implement #15 (get version info via the header). Just add the header to the collectHeaders() function and compare with the current version.
I was think the same today when looking over your patch and outstanding issues , maybe a holiday project when I get home.
Thank you for creating a pull request to contribute to esp32OTA GitHub code! Before you open the request please review the following guidelines and tips to help it be more easily integrated:
Describe the scope of your change--i.e. what the change does and what parts of the code were modified. This will help us understand any risks of integrating the code.
This is a pretty big change: I've switched everything to HTTPClient, so you don't need to worry about http vs. https anymore. This however breaks any old code, that would rely on the secureEsp32FOTA class.
With this change you can use https in your checkURL as well as for the actual firmware download. It will expect an SPIFFS partition with a root_ca.pem of your webserver, so it can validate the certificate.
With this change you can still opt to validate your firmware image. I realized that it's a bad idea to have the signature_check option in the firmware.json. A MITM could easily just disable the function and load their own application. So now you define if you want to validate your firmware-image during compile time and not during runtime anymore.
This will break any code that relies on the secureEesp32FOTA class. Everything can be done out of one library, the URL you provide decides if it's secure or not.
I've tested with signature check enabled
Thank you again for contributing! We will try to test and integrate the change as soon as we can, but be aware we have many GitHub repositories to manage and can't immediately respond to every request. There is no need to bump or check in on a pull request (it will clutter the discussion of the request).
Also don't be worried if the request is closed or not integrated--sometimes the priorities of esp32OTA's GitHub code (education, ease of use) might not match the priorities of the pull request. Don't fret, the open source community thrives on forks and GitHub makes it easy to keep your changes in a forked repo.
After reviewing the guidelines above you can delete this text from the pull request.