Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - LeoNeeson

Pages: [1] 2 3 ... 46
Beta / Re: version 2.4
« on: Today at 07:25:05 AM »
I found another thing: I see the ok/cancel in port specifiction now can be effect by the hfs.lng translation file, but they seems have conflicted IDs to some built-in localization type strings.
@Rejetto: This reminds me that it could come handy if you can generate a new "hfs.lng" base (english) file, based on the latest build, to make it available for those who want to translate HFS. Maybe you can also upload it to GitHub, to make it easier to find. (I don't need this, I only comment you this as a reminder to you. ;))

Beta / Re: version 2.4
« on: May 25, 2020, 07:48:45 AM »
ok Leo, i've used flashget and i've found the bug in HFS. It will work in next release.
(Sorry for not leaving this message earlier, yesterday)

I've tested Beta 3 (I've skipped Beta 2), and the FlashGet problem was finally SOLVED!. So far, I have not encountered any other problems. :)

Stay safe people, and congrats to Rejetto for how v2.4 is going (the subtle change of colors was a nice touch). Glad to see lng support is back. :D

» Personal note: From now (until further notice), it will not be possible for me doing 'deep' testings of new builds as before, for as much as I would like to. As I've said previously, on the last past week I've started working again, and my free time is again being very limited. Besides that, I don't have a IPv6 connection to make tests, so, I hope any of you make those tests and check everything is OK. If you have anything to say to me, please leave a message on the public forum to get my attention (since I won't be logging here unless I have something to post, and I won't be checking emails as often as before). However, I'll keep an eye on the forum as always.

Programmers corner / Re: delphi 10
« on: May 20, 2020, 07:56:25 PM »
ok Leo, i've used flashget and i've found the bug in HFS. It will work in next release.
Good! :)

Leo, chill out, have some margarita, you don't need to always specify that your opinion counts so little :D Use the standard IMHO disclaimer.
I'll keep that in mind, thanks... ;D (maybe I have my self-esteem low? :o)

Did you see my email about the chrome version?
Done! (I've replied the email). Sorry for the late reply and thanks for the heads up. 8)

Programmers corner / Re: delphi 10
« on: May 19, 2020, 07:35:35 PM »
You sure? I expect this: the browser gets a cookie, then you pass the job to the DM which will get the cookie
1) from the browser, all working, directly
2) through the URL, the DM should have no cookie at this moment because didn't interact with the server yet, it sends a request without a cookie, the server accepts the SID in the URL.

I don't see in which case you should have 2 different SIDs.

i will wait your reply first.
Exactly! I'm getting 2 different SIDs: one in the browser (where I copy the link with SID), and another different SID is received by the DM (after the DM sends to HFS the link 'with SID in the URL'). :(

These are all the steps on how I'm testing this (using my DM: FlashGet).

1) I open my browser and I copy the link with 'SID in the URL' (I don't use any 'browser integration with DM', but instead I manually copy and paste the link on the DM). On HFS I have enabled the option 'Include password in pages'. And before I leave the browser (Chrome), I check the SID cookie value of my browser (using chrome://settings/cookies), and it gives (in this example), the SID: PBuQoFR45UAAAICpsLLLPw (I did this to compare it with the SID I've got on FlashGet).

2) Then, I go to my DM (FlashGet) and I manually paste the link there (I'm pasting the link with 'SID in the URL'). And this is the result:

Code: [Select]
Tue May 19 15:29:48 2020 HTTP/1.1 403 Forbidden
Tue May 19 15:29:48 2020 Content-Type: text/html
Tue May 19 15:29:48 2020 Accept-Ranges: bytes
Tue May 19 15:29:48 2020 Set-Cookie: HFS_SID_=G2SSqVR45UAAAABUNrjvPw; path=/; HttpOnly

Like you said, the SID in FlashGet should have the same SID than the browser (since the FlashGet result is a response from the server), but instead, HFS is giving to FlashGet another SID (G2SSqVR45UAAAABUNrjvPw).

That's why it fails, because the DM is getting a different SID... :-\

Programmers corner / Re: delphi 10
« on: May 19, 2020, 07:30:55 AM »
Talking about FlashGet, it's now giving a forbidden error: "HTTP/1.1 403 Forbidden". Using your last Alpha11 or the Beta1 build doesn't changed functionality with FlashGet, when using the new URL scheme (?mode=auth&u=USERNAME&e=TIMESTAMP&s2=SIGNATURE). If I'm not mistaken, this could happen because this new URL scheme relies on JavaScript to complete the login and redirecting to the resource (correct me if I'm mistaken).

in your example the session is empty. In such case it is ignored and the URL is used instead. Isn't this enough?
I've removed that part in the example (because it's not relevant), but that doesn't mean the SID is empty (it is 'Set-Cookie: HFS_SID_=xxxxxxxxxxxx', where xxxxxxxxxxxx is the radom SID).

If you want, it's better that you download FlashGet (on you XP virtual machine), and see how it works (it would be easier for you to solve the error). I recommend you to install on a virtual machine this FlashGet v1.6 (it's an old version which doesn't install adware if you choose to install it as shareware).

But don't worry about this FlashGet thing (if it's too complex to fix). If it can be solved good, but if not, it's OK for me (that error doesn't affect me too much). :)

HFS ~ HTTP File Server / Re: rethinking the template
« on: May 19, 2020, 07:04:35 AM »
On second thought, I'm not so sure if a big change on the template editing could be of any good (like my suggestion #5, that could break compatibility with old diff-templates). Template editing was a success of HFS.

Freedom is always appreciated (some users generally want to have complete control on how the template looks). And editing templates gives some users the enthusiasm of being part of the HFS community. Removing template editing it's like cutting a dog's tail...

If it were possible, the security features you are most worried about, should "moved" to be done at server level, at not a client level (on the template), since users could break things when they edit the template. To give you an example, the last feature you added (URL with session), depends on the end-user have JavaScript enabled (if JS is disabled, the resource doesn't load until the page is refreshed). Nowadays all browsers have JavaScript enabled, so that's not a problem. What I'm trying to say is that if somehow we remove this JavaScript dependency, this new feature would work independently of which template the user have installed.

I personally always used the default template (the old and now the new one), because it has all what I need (with a good design choice), but some users want to have almost everything included (an audio player, an image preview, image slideshow, etc), and they are happy editing the template.

So, I think it's server's administrator responsibility their own server's security. From my point of view, is beyond your responsibility if the server admin change your default template and break things. You could make it very clear that 'warranty is void' if the default template is changed, and you can display a 'warning message' on the first time the admin changes the template (if that makes you feel better).

Well, my opinion is not relevant, after all it's your choice and preference. Like we all say here, you are the boss and your decisions will be respected, whatever decision you take (and you always have made good decisions about HFS's functionality, and have designed the template with good taste). So, feel free to do what you think is best. :)

(I hope some other users can also join this discussion, and leave an opinion about this on the next days).

HFS ~ HTTP File Server / Re: rethinking the template
« on: May 18, 2020, 10:42:45 PM »
Example of how the headers described on my point #5 could look (I do this, to avoid confusions).

Code: [Select]
// ==HfsTemplate==
// @ID:            MTIzNDU2Nzg5MA==
// @title:         New modern template for mobiles
// @comments:
// @description:   This template is meant to use on mobiles with small screen.
// @author         LeoNeeson
// @updated        2020.05.18
// @version        1.2
// ==/HfsTemplate==


And the validation of the diff-template is done with @valid-for:

Code: [Select]
// ==DiffTemplate==
// @valid-for:     MTIzNDU2Nzg5MA==; NTY3ODkwMTIzNA==
// @description:   This is small mod for the cited templates
// ==/DiffTemplate==


The user can add more custom '@tags' (which could be ignored by HFS), but (on my example), only 2 tags are mandatory: @ID: in normal templates, and @valid-for: in diff templates. This is only an idea, you can leave a comment if you like it or not (and for anyone reading this, this is currently NOT implemented, and it could never be). Anyway, I'm only commenting this to give Rejetto some inspiration (he could use this or any other method, or not use this at all). :)

HFS ~ HTTP File Server / Re: system icons
« on: May 18, 2020, 09:36:24 PM »
:) Yes, I already know that v2.4 is using embed fonts in CSS (currently using Font Awesome, with Fontello to make the file smaller and only load the icon fonts that you need). Remember this post? ;) (I was who suggested you to use Fontello).

I thought you were going to change all those embed icons for unicode icons (like on DJ's templates). Since you said "some templates are already doing without", the first thing I thought you were planning to use unicode icons (instead of using WebFonts). Sorry for my misunderstanding... :-[

Are you planing to remove that feature then? (of getting icons for files and folders from the server's system). For me it's OK :) (if you do this to clean up the source code), I personally don't care too much about this, since the current 'webfonts' are perfect (but I personally don't like unicode icons too much).

HFS ~ HTTP File Server / Re: rethinking the template
« on: May 18, 2020, 06:48:05 PM »
I do understand your feeling, sometimes template editing turns HFS in something chaotic, and you want to have 'consistency' for all your work done (especially talking about usability and security).

Personally, I have to suggest two points more, and this is only my opinion (my own point of view, so, don't take my word as something important, since all the users have the same opportunity of leave an opinion). I know my point #4 could sound extreme, but here it goes anyway...

4) Leave TPL editing only as standalone feature (self contained templates), without hfs.diff.tpl and hfs.filelist.tpl (removing diff templates feature). I appreciate the work of some users (especially the hard work of DJ), but I have to admit that sometimes is confusing to the end-user having so many diff templates, since you could not know what template you have to use first (as base to that diff), and this could lead to confusion (and break usability). Although diff templates are a very useful feature, it could make HFS chaotic (for example, try to apply a hfs.diff.tpl to an incorrect base template and you will know what I'm talking about). The problem is, removing diff templates would make users share complete standalone TPLs, loosing official updates, so I guess nobody would like my point. So, here comes my point #5 to solve this...

5) Users have to add a random "ID" to all the templates (similar to the SessionID), and force all diff templates (which makes use of hfs.diff.tpl and hfs.filelist.tpl), to specify for which "ID" are designed for (it could have more than one ID, separated by a comma), and load that diff template ONLY in case the main template is installed and matches any of the IDs for it was designed (if it doesn't match the ID, then don't load it). This way, we remove the possibility of having template chaos. You could get some inspiration on how Greasemonkey scripts have a commented 'header', where a lot of details are specified, for example, see this script header).

» Conclusion: Between your 3 points, I wold vote for point number 1, since it's the less restrictive, but I also like my point number five. About your point #1, I would make a library of all what you consider essential, for example you could have something like "/?mode=section&id=essential.js" and I would force this to be included on the html head of all the templates (and this would keep security without affecting the design of other templates).

Well, that's my 5 cents opinion. :)

HFS ~ HTTP File Server / Re: system icons
« on: May 18, 2020, 06:38:15 PM »
I've voted for "I don't care if they are different. I just want them to be nice.", but it would be nice if an option is left (on HFS's menu) to enable the old feature (if the user wants). Unicode icons (as well as emojis) are nice, but some operating systems doesn't have complete support for them. So, even if you use unicode icons by default (which are nice), if you leave an option on HFS, then users could enable that feature again (for getting icons from the server). Well, it's just my opinion... :)

Programmers corner / Re: delphi 10
« on: May 16, 2020, 05:42:25 AM »
i re-made the copy url with password feature, with the encryption

Cool! That's AWESOME! Some users were wanting this feature, so, that's fantastic news! :D

I only had time to make a very quick test today. I will do more tests on this weekend (and report back the results). Have a nice weekend people... :)


But I did'nt find a "copy url with password" menu option.
You have to right click on any file you share on root (it doesn't work for real folder files), and you will find it... ;)

HTML & templates / Re: Alternative login form for modern browsers
« on: May 16, 2020, 05:22:34 AM »
Saved should be only password hashed with salt.
and that's what i could introduce with little work.
I agree and understand on the security points (and I already know we are talking about the server side, not the client side), but I have 2 considerations to suggest you keep in mind:

1) make this optional (I'm talking about saving password hashed with salt), why? because what happens if the user lost his password, or if you use this only between family members (and then need to remember someone his password). Reset password could be handy, but it's cumbersome if HFS is used only between trusted members.
2) if this is implemented, I'm having an idea to suggest about having a way to manage sessions. I will describe this idea much better on a future post this weekend, now it's late and don't have time to leave the whole idea on how this works (my idea doesn't affect directly this, it's a supplementary thing, so, if you want to work on this, don't wait for my comment).

That said, I'm not against this (on the contrary, I think it's a cool feature for those who need it) :)

Programmers corner / Re: delphi 10
« on: May 14, 2020, 07:22:25 PM »
Anyway, it should be fairly simple to make a "copy url with session" feature, even in the template itself (the web GUI). The server have to 'get' it, but it will soon.
I like that approach :) I will wait the implementation of "copy url with session" in some of your future builds. Even if it's easy to modify the template, I vote for adding this as an option in the menu (see my suggestion below), to make easier to enable this independently of which template the server admin is using (and to avoid people come here asking for help about modifying the template).

» Suggestion: This function is now obsolete:

Menu > URL encoding > Include password in pages (for download managers)
(which makes this URL: http://user:pass@

It could be replaced with:
Menu > URL encoding > Include authenticated session (for download managers)
(you could use another text description, but I think this is clear enough)

» Important detail: If the Session-ID is contained in the URL, it should work independently and override the cookies that a download manager could generate (and send on the HTTP headers). For example, FlashGet uses (on the backend) the cookies of IE, but if the user is using Firefox to login (and authenticate), there is no relation between the download manager and the browser. FlashGet generates and negotiates his own cookie (like if it were a browser), so, if you implement this, if the Session-ID is found in the URL, it should override the 'Set-Cookie: HFS_SID_=' sent in the headers of the download manager, or otherwise it will no work (because the FlashGet cookie is independent of the browser). I can provide more details if this is not clear for you (on how FlashGet works), but it works on the same way in another independent download managers, which -are not- a browser extension. Also think on some other users, which are using HFS as a simple binary file server (like this user, which was needing to remove Set-Cookie and ETag), but could want to have password-protection.


Programmers corner / Re: delphi 10
« on: May 14, 2020, 06:34:45 AM »
The good...
I'm surprised of all the good work that has been done in only one day!:

» Alpha 9 (hfs24pre09): Now it runs perfect on Windows XP! All the graphical issues were solved. Thanks to Mars for giving all the needed help to Rejetto, and also thanks to Rejetto for the good willingness of keeping XP support (good work to both of you!).

» Alpha 10 (hfs24pre10): Login now has UI (User Interface) consistency between folders and files, and it always shows the modal when needed (the browser's login popup is finally gone, and I'm happy on how well HFS is working).

The bad...
Everything is working so well (on hfs24pre10), than I'm afraid to report this:

» Login broken on Download Managers: If you try to download a password-protected file using a download manager (like FlashGet or DownThemAll!) it fails (using a browser is OK). On hfs24pre07 everything was fine (it downloads a password-protected file normally, as it should), but a bug was introduced on hfs24pre08 (and it continues on hfs24pre09 and hfs24pre10), and it's giving this:

Thu May 14 00:35:22 2020 Connecting [IP=]
Thu May 14 00:35:22 2020 Connected.
Thu May 14 00:35:22 2020 GET /favicon.gif HTTP/1.1
Thu May 14 00:35:22 2020 Host:
Thu May 14 00:35:22 2020 Accept: */*
Thu May 14 00:35:22 2020 Referer:
Thu May 14 00:35:22 2020 User-Agent: FlashGet
Thu May 14 00:35:22 2020 Pragma: no-cache
Thu May 14 00:35:22 2020 Cache-Control: no-cache
Thu May 14 00:35:22 2020 Authorization: Basic dGVzdCUzQXRlc3Q=
Thu May 14 00:35:22 2020 Connection: close
Thu May 14 00:35:22 2020 HTTP/1.1 401 Unauthorized
Thu May 14 00:35:22 2020 Content-Type: text/html
Thu May 14 00:35:22 2020 WWW-Authenticate: Basic realm="Invalid login"
Thu May 14 00:35:22 2020 Accept-Ranges: bytes
Thu May 14 00:35:22 2020 Set-Cookie: HFS_SID_=UmVqZXR0b0lTYUdlbml1cw; path=/; HttpOnly
Thu May 14 00:35:22 2020 Error occured!

Besides the problem I've reported with download managers, I can't reproduce the last error reported by Mars.

Bug reports / Re: Bug: Logout function at server level [Fixed]
« on: May 13, 2020, 04:20:54 AM »
I hope that's fixed, you'll tell me.
I've tested the new build [v2.4 Alpha 8] and I can confirm the logout is now 100% -totally and absolutely- perfect (the small issue was finally solved!). Congratulations!

Pages: [1] 2 3 ... 46