version 2.4

[rejetto]

i'll better explain this new anti-DoS mechanism i just introduced:

since HFS listing of folders can be heavy (especially with its stupid programming language ) there is a limiter for these kind of requests:
1) 1 ip can make 1 request at a time, otherwise it is postponed
2) after finishing, the same ip cannot make another request for 1 second.
3) there is a limit of 3 concurrent folder listings. Having more would slow the users' experience uselessly.

In next release (RC2) I'm improving rule#2 by applying the 1 second only if the server is very busy (that is: having the max number of concurrent listings).

At the moment there is no 'queue', the browser is just told to try later (and it will automatically in a couple of seconds). This relieves the server from some burden.

If necessary i will introduce an option to configure this behavior, we'll see.

Other requests, like for files or icons, are not subject to this limiter.

[NaitLee]

The 429 code also happens in Takeback (0.14b) with background image function enabled (by editing tpl file). Only in RC1.
This function also requires a filelist, which acts similar to the "get list" in default template of 2.3.
Thus the page bg is always blank without an image.

Seems this anti-DoS is too strict...

[NaitLee]

@Windows Defender:
  Ah, yeah, you now said that straightly.
  But I don't know why you think a web server is a threat and unwanted.

[rejetto]

The 429 code also happens in Takeback (0.14b) with background image function enabled (by editing tpl file). Only in RC1.

i tested it with RC2 and no problem.
But you should support the 429 code, because it may happen on a busy server.
In case of 429 you have to retry.
If you don't, the bg may not show on a busy server. Nobody dies.

[rejetto]

@Windows Defender:
  Ah, yeah, you now said that straightly.
  But I don't know why you think a web server is a threat and unwanted.

they assume you are clueless and you don't know what's happening, somebody else put the server on your machine

[NaitLee]

they assume you are clueless and you don't know what's happening, somebody else put the server on your machine

The "somebody" is the HFS update/rollback batch

The retry-on-429 is done

Another thing:

I see some information about HFS is appended at end of an error page. But it also always includes the script jquery & "lib.js", even when in other templates and it's useless. This extra-loaded js will slow down some templates that needs response fast like Throwback (if it updated).

And the appended "HFS" object, how about add "var" before, to be compatible with "use strict"; ?

[rejetto]

it's because of the new system that automatically inherits the default tpl.
enter this section as empty in your tpl:
[error-page]

[rejetto]

you should consider to actually use the error-page feature to put the common code shared by all your error pages

[rejetto]

https://github.com/rejetto/hfs2/releases/tag/v2.4-rc02

[NaitLee]

I tried an empty [error-page] but that did no work.
So I had a look to default template, and got that:

Code: [Select]

[error-page]
%content%
With THIS in tpl makes the error pages work and pure
That %content% places for specific error pages. Feel free to add other things.

[rejetto]

consider i made a test with your tpl just putting [error-page] at the very end, and it fixed the problem

[MarkV]

thanks mark but it's not randomness we need for this (salt excluded)

Oh, so I didn't understand right. You want to encrypt the new password with the old one, send it and have HFS decrypt it, before replaceing and dispose of the old credentials.

That's good, however, one small thing to consider. If HFS follows good security practices, it will NEVER store the password itself. Instead, it will calculate a strong digest (like SHA512) and store that, probably salted. When a client sends the password, calculate the SHA512 digest of the sent password and then compare the two hashes.
Advantages: Passwords cannot be stolen from the server configs as the server doesn't store them; strong hashes are irreversible and have no known collisions.

In that case, you would encrypt the new password with the old password's hash, not with the password itself.


Edit: Default template also looks good in dark:

[rejetto]

correct, and i knew that, it's in the to-do since long
for a later release, we have even too much stuff here. Initially i meant 2.4 just for the mobile tpl

[rejetto]

Edit: Default template also looks good in dark:

i see you are using some other way to have it dark but i trust you know that you get a similar result by clicking the bulb icon on the top-right corner

[MarkV]

correct, and i knew that, it's in the to-do since long
for a later release, we have even too much stuff here. Initially i meant 2.4 just for the mobile tpl

Sorry, I was long absent. Lost quite some (dev) time.

i see you are using some other way to have it dark but i trust you know that you get a similar result by clicking the bulb icon on the top-right corner

It's an extension in my browser.

Will pressing the bulb be saved, possibly by account? Is it controllable, possibly even by day/night cycle?