2.4 template-making guide

[rejetto]

wouldn't it be simpler to name the accessible sections by url by preceding their name with ~( except for [] ) as [~login]
this would no longer pose a problem of interpretation and unnecessary option writing

an interesting suggestion, but would mean to introduce a new syntax, while the section flags already exist, and for this kind of purpose

[danny]

i'm just worried about the server giving 429 only for folders and not other cases, because it would be a bug.

I wouldn't worry about it except for this:
<script src="/~sha256.js">
should be changed to
<script src="/~sha256.js" onerror="this.src='/~sha256.js'">

No matter which limit, connections/429/downloads... the important externals need onerror added.
Problem:  onerror retries too fast.  Is there a way to slow down the retries by 200ms each?

...At the moment sections are always directly requestable unless the 'private' flag is set on each of them.  I think this is not a good idea and we should invert the logic......This mean all the sections that needs it should set a 'public' flag (as opposite to the 'private'), and the 'private' would just be ignored....

I don't mind adding |public to sections that are linked-to. 

Have linked to these and cannot add public to them:
~folder.tar
/~sha256.js
%encoded-folder%
%list%

Here is a template with the |public section changes added (attached)
You could test with it

[rejetto]

I wouldn't worry about it except for this:
<script src="/~sha256.js">
should be changed to
<script src="/~sha256.js" onerror="this.src='/~sha256.js'">
No matter which limit, connections/429/downloads... the important externals need onerror added.

i can tell you that a request like that won't be affected by the anti-dos. Just double checked.
I know the problems that can produced by some user configured limits. I'm not currently trying to avoid them, never did in 15 years.
Maybe in the future, but the onerror would work only for a second attempt, not the best that can be done (using js).

Problem:  onerror retries too fast.  Is there a way to slow down the retries by 200ms each?

try this
onerror="setTimeout(()=> this.src='/~sha256.js', 200)"

[danny]

onerror="setTimeout(()=> this.src='/~sha256.js', 200)"

Thanks!!!
That really helped. 
Now the retries don't jam the server.   
I used 500 for images retry on my photo version. 

[LeoNeeson]

This mean all the sections that needs it should set a 'public' flag (as opposite to the 'private'), and the 'private' would just be ignored. [...] Comments?

Since v2.4 won't be compatible with 2.3 templates, I think the idea is good.

wouldn't it be simpler to name the accessible sections by url by preceding their name with ~( except for [] ) as [~login]. this would no longer pose a problem of interpretation and unnecessary option writing

I also like Mars's comment, of doing a "white-list" of allowed sections (with the name of the 'most common' and 'most used' sections). Sections on the white-list doesn't need to have a 'public' flag (the could have it, but it would not be mandatory). And all the sections that are NOT in the white-list would be automatically 'private'. So, the logic would be: if a section doesn't have a 'public' flag, and is neither on the 'white-list', then that section is private.

Since we talk about changes, how about changing the way to call a section (and file sections) "~" to "?" (since that's the most common way of doing it). For example: "/?login" (instead of "/~login"), or "/?lib.js" instead of "/~lib.js". This would bring consistency with the current: "/?mode=jquery". If I'm not mistaken, this idea was on the to-do list. To keep compatibility, you could make both ("~" and "?") as valid options.

Cheers,
Leo.-

[rejetto]

I also like Mars's comment, of doing a "white-list" of allowed sections

i don't think mars suggested that, so i will consider it your suggestion

if a section doesn't have a 'public' flag, and is neither on the 'white-list', then that section is private.

i see, but i don't think we need two methods on this

"~" to "?" (since that's the most common way of doing it).

the ? is a standard, yes, and we have it the standard way, with ?mode=section&id=
having ?whatever is not the common way of using the ? and is a very dangerous choice, because sections can have any name, and you can pass other parameters a lot of confusion can arise. If still have ~ to stay short.

[danny]

Sometimes we would link to items which are located inside of the .exe.  I can't edit to add public to those. 
So, if they should be linked to; then, that would be a good use for a white-list.
Although, an actual white-list function is not really required for that.

[LeoNeeson]

i don't think mars suggested that, so i will consider it your suggestion

I must have misunderstood his message then (or he inspired me that idea).

My white-list idea is having on the template a place where we declare all the public sections at once. For example, something like this (see the line marked in red color):

[+special:strings]
public.sections=[common-head];[];[style.css];[upload];
option.newfolder=1
option.move=1
option.comment=1
option.rename=1

This way, it's much easier to visualize all the public sections at once (and it's less work when adapting the old templates, since it's just adding one line of text). This is only an idea (it's currently not implemented). What the rest of you think about it?...

Sometimes we would link to items which are located inside of the .exe. I can't edit to add public to those.

I guess if Rejetto implements this, it would not be required to declare 'public' a link like "/?mode=jquery".

Cheers,
Leo.-

[danny]

Here is a bad idea with gallery view, but it might be useful for testing, RC4

The template attached can appear to work for localhost/lan, but probably not do for multiple users with internet connections.

To make it more informative for testing, you can find onerror="this.src='%item-url%'" and change it to onerror add to log file. 
Then you can point it at a folder with hundreds of images (or search *.jpg), scroll, and see what the limiting factors may be. 

This file is not suitable for regular use.

[danny]

RC5 is ready.

For this, add |public to sections that you link to. 
<a href="/~mysection">mysection</a>
goes with [mysection|public]

[Mars]

some sections do not need to be with public attribute because they are already included by a macro call in a public section ~style.css, ~lib.js

[icons.css|public|no log|cache]  --> {.$icons.css.}
[normalize.css|public|no log|cache]  --> {.$normalize.css.}
[sha256.js|public]  --> {.$sha256.js.}

another thing needs probably to be extended

public sections are called mainly with the reference / ~ sectionname, however in a diff template this type of section may have to be completely redefined.
Due to the inheritance principle this section is available from anywhere in the vfs using the macro {.section | sectionname.} But should also be available by adding ~ sectionname to the url of any folder element vfs as example http://127.0.0.1/New%20folder%20(2)/~test

[rejetto]

some sections do not need to be with public attribute because they are already included by a macro call in a public section ~style.css, ~lib.js

you are right, but there's a reason for it: i marked them public in case other templates want to use them by url

But should also be available by adding ~ sectionname to the url of any folder element vfs as example http://127.0.0.1/New%20folder%20(2)/~test

~ is a valid character for files, so introducing this feature was a debatable decision, i prefer to not extend it to folders.
it is also not necessary because you can use use ?mode=section with folders.

[Mars]

you are right, but there's a reason for it: i marked them public in case other templates want to use them by url

~ is a valid character for files, so introducing this feature was a debatable decision, i prefer to not extend it to folders.
it is also not necessary because you can use use ?mode=section with folders.

add attached file ( which contain "this is the file" ) to root of vfs

add this section in the tpl

[test|public]
this is a section

go to this url
127.0.0.1/~test 

pay attention to the result: a recording is proposed, record in any directory and then examine the content

the file has priority over the section  whatever the chosen location.
among others:
"because we must  use use ?mode=section with folders", the name must appear in the url like all names starting with ajax.
but  all ajax sections can be made non-public for the benefit of a single section by using some changes

[ajax|public|no log]
{.check session.}
{.$ajax.{.postvar|method.}.}


[ajax.mkdir|public|no log]

[ajax.rename|public|no log]

[ajax.move|public|no log]

[ajax.comment|public|no log]

[ajax.changepwd|public|no log]

function ajax(method, data, cb) {
    if (!data)
        data = {};
    data.method = method;   
    data.token = HFS.sid; // avoid CSRF attacks
    showLoading()
    // calling this section 'under' the current folder will affect permissions commands like {.get|can delete.}
   return $.post("?mode=section&id=ajax", data).then(function(){
        if (cb)
            showLoading(false)
        ;(cb||getStdAjaxCB()).apply(this,arguments)
    }, ajaxError);
}//ajax



also added an example of a new method for changing the password, including the need for the old password and confirmation of the new one to validate the action, naturally the old password is encrypted when sent and compared by hfs to validate the new one.
it is not possible to use complex encryption for the new one but it does not appear in plain text when sent

the big advantage is that it avoids accidentally changing the current password
moving the mouse over the eyes to the right of the input fields allows you to view their content

[rejetto]

i tried your tpl, but i see no "this is the file" to be added to the root. I only see the tpl attached to your post.
Anyway, i tried with another file, renamed it ~test and accessed it. The file has priority over the section, it was downloaded, the content was that of the file.
Everything is fine, that's the expected behavior.

The single [ajax] section is not bad, i may use it for the default tpl.

Consider that asking twice the password makes the "showText" unnecessary.

You should not use {.cookie|HFS_SID_.} in a cached section. If there's a logout/login in the meantime it will still have the old sid.  That's why i use "HFS.sid".

Using the base64 just to avoid the plain text is good, i had the same suggestion from LeoNesson.

[danny]

How can I change the login section to avoid the "white screen" (bare server response) problem? 

The login section that I have been using, works right most of the time, but sometimes, it doesn't catch the server response (sometimes the user gets white screen error).

Code: [Select]

[login|public]
{.add header|Cache-Control: no-cache, max-age=0.}<!DOCTYPE html><html lang="en"><head><meta charset=UTF-8 /><meta name="viewport" content="width=device-width, initial-scale=1"><meta http-equiv=CACHE-CONTROL content=no-cache><title>HFS %version%</title></head>
<body bgcolor="black" text="white" alink="white" link="white" vlink="white">
<font size=4><center><br><br><br>
    <form method='post' onsubmit='return login()' action="/?mode=login">  <!-- return true   / -->
      <table border="0" cellspacing="20">
      <tr><td align='right'><label for="user">{.!Username.}</label><td><input name='user' size='25' required placeholder="%user%" id='user' />
      <tr ><td align='right'><label for="pw">{.!Password.}</label><td><input name='password' size='25' type='password' required id='pw' />
      <tr ><td><td><input type='submit' value='{.!Login.}' style='margin-top:13px'>
      </table>
    </form>
<font size="2">Keep me logged-in<input type="checkbox"></font><br><br>
<button onclick="var tmp=prompt('new password'); if(tmp) {var fd=new FormData();fd.append('new',tmp);fd.append('token','{.cookie|HFS_SID_.}');fetch('/~ajax.changepwd',{method:'POST',body:fd})}" hidden>{.!Change password.}</button>
<br><br>
</center>
<script>
const loc={}; loc.Logout='{.!Logout.}'  /*translate here*/
var sha256 = function(s) {return SHA256.hash(s)}
function logout() {fetch("/?mode=logout").then(res => location.reload()); return false;}
function login() {
    var sid = "{.cookie|HFS_SID_.}"  //getCookie('HFS_SID');
    if (!sid) return true;  //let the form act normally
    var usr = user.value;
    var pwd = pw.value;
var xhr = new XMLHttpRequest();
xhr.open("POST", "/?mode=login");  // /~login
var formData = new FormData();
formData.append("user",usr)
if (typeof SHA256 != 'undefined') formData.append("passwordSHA256",sha256(sha256(pwd).toLowerCase()+sid).toLowerCase()); else formData.append("password",pwd)
xhr.onload=function(){if(xhr.response=='ok') {
 if(document.querySelector("input[type=checkbox]").checked) localStorage.login=JSON.stringify([usr,pwd]); else localStorage.removeItem('login');
 location.replace(document.referrer)} else {alert("user or password don't match");document.querySelector("form").reset();location.reload(true)}}
xhr.send(formData)
    return false;
}
if(localStorage.login) document.querySelector("input[type=checkbox]").checked=true  //stop keep logged-in: call /~login and disable "Keep me logged-in"
document.querySelector("input[type=checkbox]").onchange=function(){if(!this.checked) localStorage.removeItem('login')}
if('%user%') {document.querySelector("input[type=submit]").value=loc.Logout; document.querySelector("input[type=submit]").onclick=function(){logout(); return false}; document.querySelector('button').hidden=false}
if(!'%user%' && localStorage.login) {
var tmp=JSON.parse(localStorage.login)
user.value=tmp[0]
pw.value=tmp[1]
var myform=document.querySelector("form"); if (myform.requestSubmit) myform.requestSubmit(); else myForm.submit()
} </script> <script src="/~sha256.js" onerror="setTimeout(()=> this.src='/~sha256.js',509)"></script>

[ajax.changepwd|public|no log]
{.check session.}
{.break|if={.not|{.can change pwd.}.} |result={.!Forbidden.} (0).}
{.if|{.length|{.set account||password={.postvar|new.}.}/length.}|{.!OK.} (1)|{.!Failed.} (2).}
How do I correct the white screen bug? 
It is more frequent on mobile. 

P.S.  This login section is DJ's from  https://rejetto.com/forum/index.php?topic=13060.msg1065861#msg1065861
I have made 3 changes:  I copied the change password script from release 2, I copied the ajax section from takeback, and I added page reload on bad password so that bad password can't persist.  Anyhow, the one big problem is that sometimes a successful login is met with this peculiar form of disaster: 

Looks blank, but actually says ok in dust-speck-sized print.  It is more likely to happen to the phone than the PC.
It doesn't happen so often, but I need to remove all chances of this happening. 
What is the recommended fix?
This looks exactly like blacklist (anything else) versus whitelist (nothing else) logic error.  It is currently operating like blacklist, which always needs fallback, such as timer (range 1.2s to 3s) then redirect ../

Edit, solution was to delete
action="/?mode=login