FireBrick Custom CSS: Difference between revisions

You can use custom cssCSS to override the cssthat used onby the FireBrickFireBrick’s own admin pageswebpages to customise or enhance the UI to suit your particular needs or create your own look. A user's CSS override file is specified by a URI in the XML config in an attribute on the <code><http></code> element:

The following example fragment of CSS greatly reduces the font sizes in use in the Firebrick's web pages:

font-size: x -small

div.footer, div.footer *

vertical-alignpadding: top;2px 10px 1px

padding-top: 2px;}

Completely separate 'print'- and 'screen' stylesheets can be maintained in separate .css files and these files can be conditionally included by reference in a master .css file using the CSS <code>@import</code> directive at the top of the file with a media-type qualifier within the directive ege.g. <code>@import 'my_fb_print.css' print;</code>. This qualified import form is concise compared with using thea <code>{ }</code> statement block qualifier and in theory might minimise the size of an initial CSS download, depending on the browser. A general disadvantage of <code>@import</code> is the latency introduced by additional http requests, some of which can not be parallelised, so this delay increases page rendering time, unless of course the CSS is already cached.

There is a danger of making the Firebrick’s web UI completely unusable with mistakes in your custom CSS. To avoid this possibility, if you are using the Firebrick'sFirebrick’s XML config editor page, use the "Test"“Test” button rather than "Save"“Save” after making your edit, as this will set a timer and will then roll back your change afterwhen athe timetimer expires if you have not chosen “Save” before then, so you will be automatically rescued by the limittimeout if you are stuck.

To avoid introducing delays in the responsiveness of the Firebrick's web UI, choose a well-configured web server. If you are the web master of your chosen server, review the web server’s cache-friendliness settings. (Topics: 'cacheability', 'cache-control', 'ETags'.) Getting cacheability settings wrong could in theory at least mean that your Firebrick might possibly be compelled to refetch the custom CSS repeatedly. A number of excellent web-based tools are available that willto check and diagnose cacheability issues of a website. If you are using the Apache web server, see the <code>https.conf</code> or <code>.htaccess</code> documentation relating to cache control options. SetMake longsure timeoutsthat foruser cacheabilityagents ofare allnot CSSforbidden filesfrom andcaching makedownloaded sureCSS thatfiles, theand Firebrickset islong notcache forbiddenvalidity fromtimes cachingfor theall downloadedCSS CSSfiles. Using inappropriate short cache lifetimes, even zero, or disabling caching altogether is a fairly common and heinous practice. Cache validity times should be set specifically according to each kind of file extension (<code>.css</code>) and MIME type requested (<code>text/css</code>), and should be as long as possible. The maximum validity time value is the maximum delay you feel is acceptable before a Firebrick shows the effects of a change when you change the css file on the web server.

The extent of the potential outcomes that an attacker could achieve by succeeding in pulling in an evil .css file is an open question. Some versions of Microsoft Internet Explorer for Windows could cause code to be executed when ''triggered from within a mere .css file'' by the use of the powerful non standard <span lang="en-US"><code>behavior:</code></langspan> and <code>expression()</code> CSS features. See MSDN articles on <span lang="en-US">[https://msdn.microsoft.com/en-us/library/ms530723(v=vs.85).aspx CSS 'behavior:']</span> and [https://blogs.msdn.microsoft.com/ie/2008/10/16/ending-expressions/ CSS 'expression()'].

IIt recommendis recommended that you should not attempt to include newlines in the inline CSS of your data URI, as this may be forbidden by the URI scheme standard. Be aware of the risk of your inline CSS containing characters that are either prohibited in data URIs, illegal in quoted strings or in XML attributes. See both the RFC for the data URI scheme and also the XML standards. Just some examples of illegal characters are ", %, &, >, newlines and there are probably various others, The simple technique of including literal CSS straight, as below, is only usable if the particular fragment of CSS does not contain any problematic characters, otherwise see the next section for a general method.

Example,: straight, inline CSS. (exerciseExercise caution regarding prohibited characters if adapting). In the following example, any line-breaks maywhich be included for readability. These must be removed and the whole string must be entered as a single line.

<syntaxhighlight lang=xml><http css-url="data:text/css,@media screen{div.main,div.sidemenu div.menu a,div.topmenu,textarea{font-size:x-small}div.footer,{padding:2px 10px 1px}div.footer *{vertical-align:top;padding-top:2px;padding-bottom:1px}}" />

Note the presence of the comma after <code>text/css</code>. This is essential in a <code>data</data> URI.

You may use base64-encoded <code>data</code> URIs for safety and complete flexibility as shown in the example below. Using base64-encoding removes any risks and problems with illegal characters completely. Note again the presence of the comma, now after the keyword 'base64<code>data</code>'. This is essential in a data URI, whether base64 is used or not.

css-url="data:text/css;charset=UTF-8;base64,QG1lZGlhIHNjcmVlbntkaXYubWFpbixkaXYuc2QG1lZGlhIHNjcmVlbntkaXYubWFpbixkaXYuc2lkZW1l