~migadu/alps#40: 
Bundle templates and assets

I wonder if we want to bundle the default set of templates and assets.

We want to allow users to change themes and Lua plugins at runtime, so we should keep a way to load these from the filesystem. (Maybe we should add a way to customize builds and specify a set of themes and plugins to bundle?)

Status
REPORTED
Submitter
~emersion
Assigned to
No-one
Submitted
2 years ago
Updated
7 months ago
Labels
No labels applied.

~migadu 2 years ago

Ideally a few (more than one) universal, minimalistic templates are built-in. Additional ones may be added locally at a config directory, /etc/koushin/templates/

Sysadmin may decide the default built-in template.

template=[default | name1 | name2..]

(not sure about the config vars, just a rough thought here)

The sysadmin may decide to fetch template from a remote destination, which overrides template config:

remote_template_path=.well-known/koushin/templates remote_template_domain=provider.tld

Remote templates are very handy so we providers do not have to redeploy webmail for design changes. We can just change static files on our website.

This would attempt:

https://{{remote_template_domain}}/{{remote_template_path}}/sign-in.template
https://{{remote_template_domain}}/{{remote_template_path}}/messages-list.template https://{{remote_template_domain}}/{{remote_template_path}}/message.template ...

Templates would be cached on local filesystem under provider.tld/ directory

Sysadmin may also allow domain specific templates in config:

domain_templates=yes

This would attempt on address@domain.tld (or on CNAME of domain.tld at sign-in)

 https://domain.tld/{{remote_template_path}}/sign-in.template
 https://domain.tld/{{remote_template_path}}/messages-list.template
 https://domain.tld//{{remote_template_path}}/message.template
 ....

Finally, the sys-admin config may decide to allow user overrides:

user_templates=yes

This would make URL field available in settings.

 <USER_URL>/sign-in.template
 <USER_URL>/messages-list.template
 <USER_URL>/message.template

If some is not available, the previous level is attempted (domain, default).

Wdyt?

~emersion 2 years ago

Ah, you're speaking about something different (fetching themes via HTTP), which is tracked in a separate ticket: https://todo.sr.ht/~sircmpwn/koushin/1

This issue is about embedding resources in the koushin binary.

~emersion 2 years ago

Remote templates are very handy so we providers do not have to redeploy webmail for design changes. We can just change static files on our website.

If you just want to make koushin reload its templates, we could make it so you can run systemctl/service reload koushin to do it. Instead of having to maintain a complex system to load remote templates, you can just drop files in a local directory and reload kanshi.

Is there another use-case for remote templates? (Fetching templates and assets from a remote HTTP server is potentially a security issue, and should only be done for some whitelisted hostnames.)

~migadu 2 years ago

What if the webmail is deployed on a dozen of hosts? It would require deployment. Why do you see it a security issue? System admin determines the trusted host. Then, domain (email) admin determines own trusted hosts, and finally user determines own trusted hosts.

~emersion 2 years ago

What if the webmail is deployed on a dozen of hosts? It would require deployment.

I'm not sure HTTP templates are a good solution to the "I want to deploy a theme change on multiple hosts" problem. The sysadmin will need a way to deploy regularily updates for the webmail anyway.

Why do you see it a security issue?

Templates allow to execute code on the server (see html/template docs: "The security model used by this package assumes that template authors are trusted, while Execute's data parameter is not."). Thus any template needs to be trusted by the sysadmin. Being trusted by the domain owner or the user isn't enough.

~migadu 2 years ago

I see, I did overlook the fact that we're talking Go templates here. I had in mind templates such as Markdown. I concur, lets strike the remote templates.

~migadu 2 years ago

correction: Mustache

~ogarcia 7 months ago

Bundle templates and assets with the binary is a interesting thing. There are some projects as Gogs that already do it. This would also allow the entire system to work by simply distributing the binary.

On the other hand, I think it is necessary to improve the definition of the location of plugins and themes to make it easier for the user to install alps at system level. Right now the only way to achieve this is to patch the code as is done in AUR packaging. Maybe a Makefile that allows to define the installation prefix? Something like make PREFIX="/usr/lib/alps/" for define a themes dir /usr/lib/alps/themes and plugins dir /usr/lib/alps/plugins.

~emersion 7 months ago

I think it would make more sense to set the paths at build time rather than bundling. This allows theme to be added/updated without altering the binary.

Go has a CLI arg to override a variable in go build.

~ogarcia 7 months ago

I think it would make more sense to set the paths at build time rather than bundling. This allows theme to be added/updated without altering the binary.

I think that one thing does not rule out the other, since you could bundle templates but override them if there are present on themes folder.

For example you have alps theme bundled, but in themes folder exists themes/alps/head.html then head.html is loaded from themes folder.

~emersion 7 months ago

Still, distributing executables isn't something we should optimize for. Users should use the package from their distribution.

Register here or Log in to comment, or comment via email.