delphi 10

[rejetto]

@leo, i just installed FDM to make a test and, as i expected, to make it work you have to use the browser extension, so that it will intercept the cookie/session. The URL is not enough.
Anyway, it should be fairly simple to make a "copy url with session" feature, even in the template itself (the web GUI). The server has to 'get' it, but it will soon.
Let's say the name of the url parameter is the same of the cookie

Code: [Select]

    sid:=conn.getCookie(SESSION_COOKIE);
    if sid = '' then
      sid:=data.urlvars.Values[SESSION_COOKIE];

I don't see any security problem with this. Both the data are totally controlled by the client, and it matters very little the way it sends it.

A different matter is to limit a session to a single IP, which i'm not currently doing. It's a quite a common practice, and easy to do. It's cool that it can probably be scripted in the [request] event. I'm wondering if and how i should make it.

Anyway, the session will of course not be valid when you logout, and it expires if not used in 24 hours.

[rejetto]

@mars, i too was unable to reproduce your problem.
Be sure you don't have "customized template" please, or let me know if you find how exactly to reproduce, thanks

[SilentPliz]

The problem of protected folders seems to have been solved.

A strange thing, however; the first time I launched 'Open in browser' to test on protected folder ... the 'Login required' page was displayed, without a box to enter the ID+PASSWORD.
After closing the page and relaunching 'Open in browser', it worked (ID+PASSWORD box displayed) ... I didn't understand why.

The test PC had never seen HFS, so the configuration was blank.

[LeoNeeson]

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@127.0.0.1/filename.rar)

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.

Cheers,
Leo.-

[rejetto]

A strange thing, however; the first time I launched 'Open in browser' to test on protected folder ... the 'Login required' page was displayed, without a box to enter the ID+PASSWORD.
After closing the page and relaunching 'Open in browser', it worked (ID+PASSWORD box displayed) ... I didn't understand why. The test PC had never seen HFS, so the configuration was blank.

meh, let me know if you find how to reproduce it, because an incognito browser won't

[rejetto]

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).

i already thought of this, and don't exclude having it in the GUI, but what if you want a link to a file that's in a real folder? only the web side can (for now).
Also: the GUI doesn't have a session. I should provide a new&random one in the URL itself to allow encryption.

» Suggestion: This function is now obsolete:
Menu > URL encoding > Include password in pages (for download managers)
(which makes this URL: http://user:pass@127.0.0.1/filename.rar)

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)

This suggestion you make would depend on the session. If the session expires it will not work. Is this ok, i wonder?
i'm not sure i remember the reason for this feature: to allow protected downloads for the download managers we include credentials in the URL for everyone? sounds a bit extreme :-/

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).

in your example the session is empty. In such case it is ignored and the URL is used instead. Isn't this enough?

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.

FDM (i'm using) is independent, but has an extension for extra features, like cookie catching.

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.

i don't see how this use-case is related to our discussion. It had a small buffer and wanted a smaller header

[rejetto]

i re-made the copy url with password feature, with the encryption
https://github.com/rejetto/hfs2/releases/tag/v2.4-alpha11

the new URL scheme is
http://host/file-url?mode=auth&u=USERNAME&e=TIMESTAMP&s2=SIGNATURE

u: plain text.
e: UTC timestamp in delphi format. This is optional and currently not used by GUI and default template.
s2: calculated like this: considered X as the part of the URL after the ? and before the &s2, it's sha256(X+password)

Guys.... we almost have expiring links, aren't you happy

This is different from mode=login because it's not made for ajax/form.

Anyway, i wish someone else to be checking the security of this new stuff.

[SilentPliz]

WoowwW!!!!

HFS is 18 years old ... It seems that he reaches this year 2020, the age of majority.
What great novelties !!!

Thanks thanks Boss !! 

Edit: One or 2 more days, and you will have exhausted all the todo list.

I'm a little sad that I can only test from tomorrow.

[dj]

Anyway, i wish someone else to be checking the security of this new stuff.

http://192.168.137.1/test/?mode=auth&u=admin&s2=d674e9edc3d3330c93151dad2992bc0e082a18fc6d6d6f7f1155548558f5b1b6 works (even regardless of the chosen template)!

But I did'nt find a "copy url with password" menu option.

[LeoNeeson]

i re-made the copy url with password feature, with the encryption
https://github.com/rejetto/hfs2/releases/tag/v2.4-alpha11

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

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...


Cheers,
Leo.-

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...

[rejetto]

the copy with password is available only for protected resources

[rejetto]

i want to specify that the new authenticated links don't limit access to the specific file/folder.
The URL causes a contexual login with user credentials. From there, you can continue with every other resource that's accessible for that user.

This is exactly as it was before, when you had user/pass in the URL. Functionally very similar.

Anyway, i think in the future we may have also another kind of URL, with access only to that specific file/folder.
The easy way is to sign not just the parameters of the URL, but also the resource.
But we cannot use an account password, because no account should really be involved.
So i guess the way to go is to generate a password (automatic) for the HFS instance/installation, to be saved in the INI.

[rejetto]

ok, i think next release is good for beta stage

[rejetto]

Now time to add https... (just joking)

i hope to be able to work on that soon, and maybe to have letsencrypt support as well.
consider that there may be some XP problem, because of openssl 1.1.1

[LeoNeeson]

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).