University/organization-specific adjustments (design or otherwise)

[LukasKalbertodt]

We expect that organizations (mostly universities) need to adjust the design of their Tobira instance to match their cooperate identity. This issue tracks this general feature and collects ideas and notes about the topic.

What things need to be adjustable?

• Logo & favicon
• HTML title & some <meta> information
• Main colors
• Font

Potential additional requirements

• Custom CSS?
• Two logos, e.g. the main university logo and a logo for the "digital education" section of the university. (Example)

Some general thoughts

We were tasked to make Tobira rather customizable. However, adding more way to customize Tobira adds complexity and makes everything less robust, potentially even slower. Tobira is not supposed to be a full-blown CMS or even website-builder.

Implementation ideas

Customizing Tobira should not require recompiling/bundling anything. Users should be able to grab a precompiled version, run it and change configuration files to adjust the design.

• Logo and favicon: the config file can specify paths for these images (logo has to exist in a small and large version, too). Tobira shouldn't embed the dummy logos in its executable file for production builds. Every user is going to replace those! So I'd rather make the config value mandatory.

• HTML title and metadata: this should also be easy to configure via config file. It's just strings. Probably makes sense to make these values mandatory to configure as well.

• Main colors: This is more tricky. For one, the Tobira design should use some kind of palette with a few main/accent colors. We should test the design with a couple combinations to make sure the design works with different palettes. A technical question is how to configure these colors and where to define a default. We could use actual CSS variables: our CSS code just refers to those instead of fixed colors. The backend then inserts a <style> tag with the correct definitions into index.html and then hopefully everything should work? The defaults would be defined in the backend then. And I think having a default is good in this case as not every institutions will change the default style.

• Fonts: I probably would only use one font for all of Tobira: Open Sans. Changing the font is not trivial, for a couple of reasons:

  • How to refer to the font in the frontend code? Also use CSS Variables? Maybe. Can CSS variable hold "list" as usually specified for font-family? E.g. font-family: 'Open Sans', 'Arial', sans-serif;
  • How to include the font? Currently we have a generated CSS file which includes parts of the font for different charsets. This CSS code is included in index.html. We could let the user specify a file path in the config file to a CSS file doing the same.
  • If the font files are served by Tobira, how to include those files? Probably again a path in the config file to a folder that is server under assets/fonts/.

The other "potential" requirements seem rather difficult to implement. Custom CSS is tricky as we use CSS-in-JS. I don't know how a raw included CSS could best overwrite values set by JS. Two logos or a notably different page layout is also pretty tricky: I wouldn't know how to support that.

[JulianKniephoff]

• [...] Can CSS variable hold "list" as usually specified for font-family? E.g. font-family: 'Open Sans', 'Arial', sans-serif;

Yes, they can.

[lkiesow]

• Logo & favicon
  • Should be adjustable and there should be a default so that people know where the logo will end up. But the default could pint to a central location. For example, Greenlight points by default to a BigBlueButton logo hosted on GitHub.
  • The configuration value could just be a URL. We don't need to care about how people serve these files.
• HTML title & some information
  • Sounds reasonable and should be easy enough. We don't need to overdo it though.
• Main colors
  • Defining three main colors would be great. We could dynamically generate a CSS file to include. We should avoid generating the style inline (content security policy).
• Font
  • We choose the font. And it's Comic Sans (obviously)! – Seriously, I don't think we need this configurable.
• Custom CSS
  • Should be easy enough and should deal with all the ugly edge cases. You want three more logos and text should be blinking? Go crazy…
• Two logos, e.g. the main university logo and a logo for the "digital education" section of the university.
  • I wouldn't. It's an edge case of which you can find hundreds.

[LukasKalbertodt]

We don't need to care about how people serve these files.

Mh good point. I guess if we recommend an nginx (or whatever) in front of tobira anyway, they can also add some filter/handler for static files there. However, I think I would still prefer if Tobira would serve that file. And it's really super simple to implement and would be a bit more convenient for users. Will see.

We should avoid generating the style inline (content security policy).

Can you elaborate on that? Inline CSS in the main HTML file shouldn't be a problem, right? But I also don't know a lot about CSP.

We choose the font. [...] I don't think we need this configurable.

I also don't want to make it configurable. Not only would it be more work for us, other fonts could easily break some parts of the design. However, I guess that's not entirely our decision to make, right? If most institutions would strongly require their fonts to be used... ?

[lkiesow]

Can you elaborate on that? Inline CSS in the main HTML file shouldn't be a problem, right? But I also don't know a lot about CSP.

Having inline scripts and/or styles requires script-src/style-src set to unsafe-inline. The basic idea behind avoiding this is that it's way harder for attackers to inject unsafe code if you can't just include it and if – best case – it's even narrowed down further to something like …-src 'self', where you would need to be able to serve a fine from the same domain to include it.

Scripts are obviously more problematic here but even with injected CSS you can do nasty things (e.g. loading trackers, …).

Obviously, the goal should be to avoid injection altogether but the CSP is basically a nice second line of defense.

[lkiesow]

However, I guess that's not entirely our decision to make, right? If most institutions would strongly require their fonts to be used... ?

For now, I think it is and we shouldn't push for it. If you start asking people if they really don't need special fonts they will surely need it. The requirement has never popped up anywhere except for you pushing it here, has it?

[LukasKalbertodt]

Regarding CSP: interesting, but makes sense, we probably want to avoid allowing unsafe-inline.

It's worth noting that we currently already use inline <style> to include the custom fonts. Also note that our main CSS code is defined in JS (CSS-in-JS library), so there is no .css file that we currently serve anywhere. Of course we can push that to an external CSS file. Will see about that.

The requirement has never popped up anywhere except for you pushing it here, has it?

Well, not specifically regarding Tobira, no. But I talked to two people asking about the CI/CD of their university and they both mentioned fonts as something that should be adjustable.

But ok, then let's not implement that for now.

[JulianKniephoff]

Regarding CSP again: There is also possibly a middle ground between unsafe-inline and specifying origins (including self) and thus allowing only files: See the last two options in the sources list here.

We would either have to generate a nonce on every request which we then inject into the inline styles, or we just hash the inline scripts/styles and list these hashes in the CSP.

This is spec'ed in CSP Level 2. Browser support is not perfect, yet, but should suffice for what we want.

I would prefer that to deoptimizing our styles/scripts or otherwise letting this influence our decisions regarding how we use JS/CSS in the app. Plus, certain dynamic styling things just aren't possible or much harder if you are restricted to just static files. I don't know if we need any of those, but thinking about configurable styles -- depending of course on how exactly they will be implemented -- it certainly doesn't sound too absurd to me. :thinking: