i can come up with a PR to get this feature implemented

Hi @UiP9AV6Y

Thank you for your contribution!

It's an interesting idea, although the templating was never an advertised feature of this service, more like a convenience.

For standard pages (index, baskets, basket) I do not need the power of Sprig, I guess.

For responses Sprig probably offers more flexible and powerful language that is easier to use, but it comes with a price. As I can see the language offers some powerful features that can easily lead to a security issues, especially since the template themselves can be created by any visitor of the web-site w/o authentication. I appreciate your effort to mitigate that by removing 3 known functions that may lead to an issue. However, if tomorrow a new version of Sprig will arrive and introduce a new dangerous function - this can lead to a security vulnerabilities by simply automatic update.

From that point of view it would be great to introduce Sprig as an alternative template language that is not used by default. And extra parameter for the service to switch between template engines. I think this should be fair: keep the default language from Go lang, that is simpler, yet safer, and let users configure more complex engine at will with responsibility of higher risk.

What do you think?

For standard pages (index, baskets, basket) I do not need the power of Sprig, I guess.

i know. i just applied it to all templating use for consistency reasons

As I can see the language offers some powerful features that can easily lead to a security issues

can you name an example? the current iteration of the templating feature already has access to request data. using sprig offers simply new ways to process that data + generate (non-sensitive) data (e.g. time, date, random strings)

However, if tomorrow a new version of Sprig will arrive and introduce a new dangerous function - this can lead to a security vulnerabilities by simply automatic update.

i assume you do not blindly update dependencies without checking what has actually changed b/c the same can be said about any 3rd party code

keep the default language from Go lang, that is simpler, yet safer, and let users configure more complex engine at will with responsibility of higher risk.

user refers to the server operator here, right?

The ability to build a dynamic response is pretty important because many webhook subscriptions require a dynamic response in order to verify the endpoint is willing to accept the webhook.