Help starting and securing HFS

[Tsuna]

I wanted to run a fie download server with HFS and got stuck with some issue

The setup I'm aiming for is like this

for site.com (where links will be posted)
and say.. files.site.com (the URL for the files)
Links to stuff on-site >> a proxy server over Nginx to secure my source server > links

Problems, major problems that I'm stuck with
1. How to configure referee function on rejetto, such that if a user takes a files.site.com/linktofile URL and steals is, they cant use it.
Ive no idea how I can get the referee to work, what should we even write here? https://site.com ? (didn't work)
Maybe my Nginx isn't passing it, idk.

2. How do you control/disable "get list" function
I can edit the HTML and remove the button, but it wont matter if a user knows I'm using rejetto's fs, go to files.site.com/?tpl=list&folders-filter=\&recursive
And done, all links are yours (getting point1 to work would be a great help here though)

3. If a user downloads files.site.com/stuff/file1 he can figure out file2, file3 and so on. (This I actually asked in a different thread, if I can get point 1 and 2 to work, I can fix most of the damage)

I really want to use this to deliver my files but cant cause once I do, people are bound to steal the links and I'm done for. :/
Kindly assist, if this can be worked around, id like to know how.
If this cant be worked around, id like to know that as well so I can give up on this idea entirely.

[LeoNeeson]

About your point number 1, besides a complex idea I've posted here, I think the best approach for this would be if this is implemented natively on HFS. I guess something like this could be done using when 'Virtual folders' (VFS or Virtual File System), and not 'Real folders' (because files are listed and read on-the-fly), but the VFS has the potential to have this. How it could work? HFS could generate and "ID" (identifier) for each shared file, and store that ID on the VFS. If this is implemented, then we could have 2 options (when right clicking on a file, on the HFS file tree): 'View share link' and 'Change share link' (the first could show the link with the current ID of the file, and the second could change the ID and generate a new one, something useful if the link is being misused and you want to re-share the same file with a new link). Then we could also have an option to only allow download using 'Share links' and disable direct file access (even if the user knows the right path of the file), and on this mode, of course we also would need to disable file listing (making a folder 'Not Browsable'). But currently this is only an idea (and I don't want to sound rude, but don't expect it would 'magically' be implemented on HFS, so if you know some Delphi expert that could help you, suggest him to visit this forum). If Mars or Rejetto has the time to add this, that would be nice, but sadly most users here have very little free time to dedicate to HFS (since this it's like a hobby for most of us).

Continuing with my idea, I think old MegaUpload links were cool (feeling nostalgic about those days ), and they had an eight alpha-numeric (uppercase) identifier for each file. For example: http://www.megaupload.com/?d=6VS2I9US and if someday this is implemented on HFS, we could have something similar, like http://localhost/?file=6VS2I9US or http://localhost/?f=6VS2I9US (where "6VS2I9US" is the "ID" of the file you want to download). That would be the ideal solution for your problem, and also an small step on making file sharing more private (without the hassle of having to set up user accounts).

About your point number 2, I think there is no option to totally disable this currently. But besides that, HFS by default doesn't allow get the list of files that are on a password protected folder. About your point number 3, it could be solved with my idea posted above.

Cheers,
Leo.-

[danny]

events (alt+f6)

[+download]
{.if|{.match|*recursive*|%url%.}|{:{.disconnect.}:}.}


The two macros that can break a connection are disconnect and redirect.

At the possible cost of hindering the search feature, you could:
events (alt+f6)

[+request]
{.if|{.match|*recursive*|%url%.}|{:{.redirect|/.}:}.}


These seem similar to HFS menu options for no archive and no recursive listing. 

[dj]

2. How do you control/disable "get list" function

Properties for folder
Flags: disable Browsable

See also http://rejetto.com/forum/index.php?topic=13262.msg1065337#msg1065337

Update: prevent edit the url

Code: [Select]

[+download]
{.if not|{.header|Referer.}|{:{.disconnect.}:}.}


[rejetto]

1.
add /* at the end
I don't remember the necessary syntax right now, but i've found this old post about it
http://rejetto.com/forum/index.php?topic=11602.msg1060404#msg1060404

[rejetto]

3. you can protect file2 from being guessed in 2 easy ways
- you can add something to the name, like file2-xyz
- you can leave the original name, but create a virtual folder xyz and put file2 there

both are manual solutions, to be done file by file.
Maybe I can invent an automatic solution, but that would require much more work.

[rejetto]

someone may want to know my other idea:
you have a secret password, and a hash function (md5/other). You make all links of files have appended ?pass=md5(password+filename)
Then you use [download] event to check the validity of {.?pass.}

[Tsuna]

Thanks for all the quick replies and the patience for the same.

I notice that HFS does include the "allow referer" option, can this now be used to control download mooching?

Properties for folder
Flags: disable Browsable

See also http://rejetto.com/forum/index.php?topic=13262.msg1065337#msg1065337

Update: prevent edit the url

Code: [Select]

[+download]
{.if not|{.header|Referer.}|{:{.disconnect.}:}.}


Will look into these.

1.
add /* at the end
I don't remember the necessary syntax right now, but i've found this old post about it
http://rejetto.com/forum/index.php?topic=11602.msg1060404#msg1060404

Oh, I'm gonna try that, if it does work then I can somewhat prevent some level of mooching.

3. you can protect file2 from being guessed in 2 easy ways
- you can add something to the name, like file2-xyz
- you can leave the original name, but create a virtual folder xyz and put file2 there

I had the exact idea, I suggested we add a small CRC code to the end of the file, this makes guess work moot.
I think virtual folders are a no no, the app itself says not to use them cause the folder size is large (8k ish files and 800gb ish)


Rejetto - ideally, all of this can be fixed if we can add a "expiring links" say, just include nan expiring token for a session so that links are only valid for that user for that session.
Deny if Ip doesn't match would work smooth.

pair this up with referer match and boom, safe and secure

[rejetto]

the "expire" thing can be added to my ?pass idea.
You add a timestamp for expiration. This timestamp must be part of the pass calculation
?pass=md5(password+filename+timestamp)

after you verify pass validity you also verify the timestamp is not old.
You leave the timestamp easy to read, as it cannot be tampered, because it will fail the password check.