Looking at this from a "skin" point of view, if a someone needs to include a script like jQuery somewhere in <head> then that skin would also need to provide CSP support. May or may not be a reasonable expectation.
I do like proposed options and would like to take them a step further, Option 5. The "header" and "footer" would no longer include anything outside (and including) the <body> tag as stated in Option 2. A new file would be added "html_head.txt" (example file name) that would include the tags to insert into Fossil's generated header from Option 1. This list of tags in "html_head.txt" would allow skins to include scripts and admins to do customization as well. On Fri, Nov 3, 2017 at 7:42 AM, Richard Hipp <d...@sqlite.org> wrote: > Fossil needs more control over the header of each HTML page in order > to insert information inside of <head>...</head> to load the > style-sheet, the scripts, and make whatever other references are > necessary. Right now, the <head>...</head> is generated by a > repository-specific "header" template, with the help from some TH1 > variables like $baseurl, $current_page, $title, $home, $project_name, > etc. > > Option 1: > > Continue to have all the <html><head>...</head><body> material be > generated from the header template as it is now. Just add some > additional variables to allow the new <link> marks required for CSP > support to be added. > > This gives the most flexibility to the site administrator, to make the > site work like she wants. But it also makes writing your own header > templates more complicated. And when new capabilities come out (such > as CSP) it requires existing repositories to edit their header > templates in order to insert the new information. > > Option 2: > > Have Fossil take over complete control of all content HTML page > continue up to and including <body>. The repository "header" template > would only generate the material that comes after <body>. For > symmetry, the "footer" template would also be changed to stop prior to > the final </body> and Fossil will automatically generate the closing > </body></html> itself. > > This approach is the most automatic. The header and footer scripts > become easier to manage, and required changes to the <head>...</head> > needed for new features (such as CSP) happen automatically without the > administrator having to make any changes. It is relatively easy to > upgrade legacy header and footer templates. Just delete all text > through the <body> in the header template and delete </body> and all > that comes afterwards in the footer. > > Option 3: > > Fossil automatically generates <html><head>...</head><body> and then > appends whatever is in the "header" template, as with option 2. > Except, if the header template already contains a <body> tag, then > Fossil assumes that the admin knows what she is doing and lets the > header template generate everything as it does now. Similarly with > the footer, Fossil will automatically generating the closing > </body></html> unless it sees that the footer script has already done > so. > > This approach continues to work on legacy repos. It allows repos to > upgrade easily just by deleting all header text up to and including > the first <body> tag. And it allows knowledgeable admins to set up > their own custom <html><head>...</head><body> text if they have some > unanticipated need. The downside is that this system is more complex > to explain and document. > > Option 4: > > Behave as in option 1 or option 2, depending on a setting. The > setting defaults to do legacy option 1 support. Then when an admin > goes to update the header and footer scripts to the option 2 style, > she also changes a setting to cause the <html><head>...</head><body> > content to be prepended and the </body></html> content to appended. > > > Summary: > > The mere exercise of writing all this down as clarified my thinking > and caused me to prefer option 3. But I'm still open to hearing other > opinions and/or receiving suggestions for other options. Please send > your feedback, even if it is just "+1 Option 3". > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > fossil-dev mailing list > fossil-dev@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev > _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
