2.4 template-making guide

[rejetto]

we should collect instructions on how to make a tpl for 2.4
let's see make a quick list
- the default tpl is always inherited. This means that unspecified/missing sections will be still taken from the default tpl. If you want to have some sections empty then you will have to have them as empty in your tpl.
- because of the point above you should probably have your [error-page]
- because of the point above, you don't need to copy libs/sections in yours, like the sha256.
- the 'private' section flag works no more. All sections are private unless you use the new 'public' flag.
- new templates (with new login system) will be recognized by the section [api level] section. At the moment the api level required is 2.
- because of the anti-DoS system, if you make XHR/fetch requests to folders, you may get an http error 429 that means you have to retry
- if your tpl works as a Single-Page-Application and doesn't use %list% in its main section, then use the 'no list' flag. That is, put this text at the top [|no list]

am i forgetting something?

[rejetto]

in RC3 you will have some new features to make tpl and diff.tpl more compatible:

[section|ver=MASK|build=MIN-MAX|template=MASK]

ver and build apply to hfs versioning, while template will match over [template id] section. MASK supports ?*; operators as usual.

Of course HFS 2.3 will not support them, but if you do |ver=2.3 it will just ignore it and keep the section, while 2.4 will know it has to skip the section.

[rejetto]

to template makers,
with these new tools I think it would be better to restore the old 'selection' name instead of 'files', so that you can more easily make cross-version templates.
What you think?
I'm not totally sure that you can make a template that works both on 2.3 and 2.4 now, but maybe yes.
I may try to make a test with the default tpl itself.

[dj]

What you think? it would be easier to restore the old 'selection' name.

My template works with both versions, but only if you add a diff.tpl.

This is because delphi checks, if a [unauthorized] section is in the user template.
If yes, the user template is rejected.

So you need to remove or rename it.

For compatibility reasons, it would be better, if
delphi checks, if a [unauth] section is in the user template and
if yes, the user template is allowed.

So you can write backwards compatible templates ([unauthorized=unauth]).

[rejetto]

initially i thought that a tpl would have not been able to be compatible.

anyway, i was forgetting an important thing: 'files' and 'selection' are not the same. Selection has double %encoding because of past unicode problems (or bad design, not sure).
you may not notice any problem while you use just ascii for filenames.
Having no compatibility with 2.3 because of the login, I didn't have a reason to keep the double encoding. Even now I don't love the idea of keeping it, but not 100% sure. I may make extra tests to see if i find a better solution.

For compatibility reasons, it would be better, if delphi checks, if a [unauth] section is in the user template and if yes, the user template is allowed.

the reason for that was that you now always inherit the default tpl, so you automatically inherit the unauth even if you maybe don't write one because you want to keep the original one.
I need to think on this.

[danny]

Can't delete.
All error pages redundant with extra scripts, extra jquery, extra css, extra footer.  Need a bypass for that problem.
I believe that the template's auto ban won't work; so, hfs.exe needs temp-auto-ban function added to the gui menu.
Login errors.

[rejetto]

All error pages redundant with extra scripts, extra jquery, extra css, extra footer.  Need a bypass for that problem.

ah, there is an unexpected behavior. A bug, i'd say.
I thought declaring an empty [error-page] would make the section empty, but it's still inheriting the default template.
Probably this was always the behavior with diff tpl but nobody noticed.
I think it should just be changed, hoping this is not breaking anything.
Consider it fixed in next release.

[rejetto]

I believe that the template's auto ban won't work;

you believe?
I would try first.
i think for improved security the event [unauthorized] should be used, because otherwise the tpl would catch only failures through the tpl's login form.
i want to introduce the ability to add events in separate file. Or maybe even in the tpl itself, why not, it would be cool and useful. I have to see what's easy to make. I'm putting this in my to-do.

[danny]

you believe? I would try first.

  I tried it from /~login.  No auto-ban, because no [unauthorized] section in new templates.  Somehow, I never arrived at the /~unauth page.  It stayed at /~login.  The model-login did not have auto-ban. 

That function would be a lot better as temp-auto-ban in the hfs menu.
Perhaps the option for temp-auto-ban could be located at the bottom of the bans page? 

[NaitLee]

ah, there is an unexpected behavior. A bug, i'd say.
I thought declaring an empty [error-page] would make the section empty, but it's still inheriting the default template.
Probably this was always the behavior with diff tpl but nobody noticed.
I think it should just be changed, hoping this is not breaking anything.

I once got the same problem around here, and there is a solution.
A single [error-page] is useless, but with just %content% below it works.

But, would this [error-page] slow down the template, or cause an slow-down attack possible/easy?

[LeoNeeson]

I thought declaring an empty [error-page] would make the section empty, but it's still inheriting the default template.
Probably this was always the behavior with diff tpl but nobody noticed.

I noticed it some months ago (when I was doing the form-based login), but I thought it was 'too much' to report it (I didn't wanted to bother you with such a small detail). I even thought it was not a mistake, but that it was done it on purpose to avoid having to write part of the 'head' section every time (so, I didn't report it). I can't remember other details now, but those were my 'breaking balls' small details that I was referring here. (Now I do understand that I have to report if I've found something, because it could be an important detail).

[NaitLee]

Can't delete.

In the del() function, replace the xhr.send(...) as:

Code: [Select]

xhr.send("action=delete&files=" + it);
Notice that "&files=", it's what "selections replaced by files" means.

[rejetto]

  I tried it from /~login.  No auto-ban, because no [unauthorized] section in new templates. 

it's beause it's an event, so it doesn't belong to the template.
i perfectly understand it's a complex system with few examples and it's hard to find the things you need.

That function would be a lot better as temp-auto-ban in the hfs menu.

that's what everybody think about the feature they want, but there's a reason why complex system are made with plugins.
This feature could make it to the GUI yes but not now, we have already too much in this, we need to stabilize.
I would not be eager if i was you, because when i'll make it you won't be able to customize it. What if you want to exclude an ip from the mechanism? The gui won't allow you that.

Perhaps the option for temp-auto-ban could be located at the bottom of the bans page? 

it's a good place i guess

[rejetto]

I once got the same problem around here, and there is a solution.
A single [error-page] is useless, but with just %content% below it works.

that's a workaround, i've found there's a bug with it.

But, would this [error-page] slow down the template, or cause an slow-down attack possible/easy?

The slowing is very little.

Notice that "&files=", it's what "selections replaced by files" means.

i'm considering going back to 'selection' before official release. I have to make a test to understand if it's possible.

[danny]

that's what everybody think about the feature they want, but there's a reason why complex system are made with plugins. This feature could make it to the GUI yes but not now, we have already too much in this, we need to stabilize. I would not be eager if i was you, because when i'll make it you won't be able to customize it. What if you want to exclude an ip from the mechanism? The gui won't allow you that. it's a good place i guess

Temporary auto ban wouldn't be such a problem.   5 fails = an hour wait.
Even if I couldn't customize it, I could wait the hour. 

In the del() function, replace the xhr.send(...) as:

Code: [Select]

xhr.send("action=delete&files=" + it);Notice that "&files=", it's what "selections replaced by files" means.

Thanks for that!