Please add URL parameters for customized firmware upgrade

[zapta]

The vid=xyz URL param is very useful as it allows to construct less confusing URLs for end users.

Please add similar params for the other aspect of the DFU flashing configuraiton:

1. DFU Interface selection. For example, a substring or a regex that matches the interface name. In my example of an STM32F401CE, it will be "0x08000000", and since it will match exactly one interface, the existing code will skip the interface selection question.

DFU: cfg=1, intf=0, alt=0, name="@internal Flash /0x08000000/04016Kg,01064Kg,03128Kg"
DFU: cfg=1, intf=0, alt=1, name="@option Bytes /0x1FFFC000/01016 e"
DFU: cfg=1, intf=0, alt=2, name="@otp Memory /0x1FFF7800/01512 e,01016 e"
DFU: cfg=1, intf=0, alt=3, name="@device Feature/0xFFFF0000/01*004 e"

2. Binary file. That is a path to a URL that contains the binary file, for example on github. In my case it can be https://github.com/zapta/simple_stepper_motor_analyzer/raw/master/releases/firmware-2021-02-01.bin

This will also allow to have on my web page multiple links, for different versions, such as stable, nightly, etc.

3. Board specific instructions. A url to a simple html page that is displayed as a frame and include board specific instructions. In my case (using WeAct blackpill), it will be a text explaining to hold down the Boot0 button while connecting the USB cable, maybe also with a picture or two.

Having such a customizable page on github will be a great tool for makers and small developers that are either don't know javascript enough to customize or don't want to fork away to benefit from all future improvements.

[devanlai]

Hi @zapta,

Thanks for the feedback.

I think adding a way to select the DFU interface when there are multiple (as is often the case for DfuSe) sounds like a great idea with no drawbacks.

I'm not as sure about allowing external firmware files or instructions to be passed as parameters. I agree that it would simplify life for developers that aren't as familiar with Javascript or have limited hosting resources, but as someone who only does a little bit more web development than the average embedded engineer, I don't think I have the security expertise to build it in a way that makes it difficult for someone to directly use the demo as an attack vector.

I can sympathize with the difficulty in building a polished, streamlined firmware updater interface - I would suggest taking a look at some of the forks if you want to see how other projects have adapted and refined the demo into something more user-friendly.

[zapta]

Thanks @devanlai, I will take a look at the forks as you suggest.

As for security, that entire thing of web pages accessing my local USB devices is strange, but that vulnerability, if it is one, was introduced by the web browsers, not by your code.