Improvements for QR codes

[acelaya]

Shlink has supported generating QR codes for some time, and allows to customize a number of things.

For all the things that can be customized, it allows to set the default value via config options/env vars, but they can be overwritten with arbitrary values at runtime, via query parameters.

So a URL like https://s.test/abc123/qr-code would generate a QR code for https://s.test/abc123 with the default configuration, and https://s.test/abc123/qr-code?size=500&format=svg would overwrite the size and format params.

This has worked well so far, but I have always felt it has some limitations:

• Customized URLs leak some implementation details which would allow anyone to generate a QR code in any color, size, etc., just by looking at the URL shape.
• URLs with a lot of query params are not as nice as the base ones.
• Defaults are set per instance, which is not super flexible if you handle multiple domains.

Because of this, I have been thinking on supporting a way to persist customized QR code options per domain and per short URL, so that when you visit something like https://s.test/abc123/qr-code, Shlink first checks if the https://s.test/abc123 short URL has its own QR code config, otherwise falls back to the s.test domain QR code config, and only if that is not found, it falls back to the defaults set via config options or env vars.

Parameters would not be mandatory, and the onse used would be the result of merging short URL-specific, domain-specific, global ones and Shlink defaults, so if a short URL does not define a custom color, but its domain does, that custom color would be used.

[acelaya]

This leaves an open question around the usefulness of query parameter options long term. If you can save the config for a short URL, does it make sense to continue allowing to customize the QR code via query parameters?

• Keep query parameters but allow them to be disabled so that they have no effect (👍🏼)
• Deprecate support for query parameters once the above is implemented, and remove them in Shlink v5 (👎🏼)

Please react to this message with 👍🏼 or 👎🏼 if you have an opinion.

[jonathandhn]

Query parameters is the right way to support non default needs (social network end users would rather access to PNG, but graphic editors would rather use the SVG version for a single given link), and not to lock end users when crafting to their needs, if someone share in public the QR URL, that is not a good practice, he should have shared the short link or the photo of the QR Code. Now yes, I do think we should be able to disable or restrict possibly to generate unwanted content as admin/owner.

Query parameters are also very useful when needing to offload some content generation (you send both the shortlink and the instruction to the external user for him to manage on its own without accessing the web client).

Actually, this is one use case where you do have a graphical guideline to respect, and I did have wanted to limit end users within specs but not to enforce only one choice too strictly. (this will query shlink QR Code by a limited set of query parameters exposed to end user)

[acelaya]

Yeah, those are good points.

Thanks!