rejetto forum

Query regarding "URL path masking"

Tsuna · 3 · 1109

0 Members and 1 Guest are viewing this topic.

Offline Tsuna

  • Occasional poster
  • *
    • Posts: 9
    • View Profile
Been a fan of HFS for years now, testing and that and using it for casual stuff.

Recently tried to setup a small server to test things out, stuck with a small issue about url path
For ex

I have hfs running at and there are files i want to provide existing at,2,3 and so on
Problem is if a user knows the path of file1, he can simply edit the url and leech.

I can block "reading,viewing" the root or "folder" so user cant view all my files but can still try

is there any setting/method i missed under hfs that allows me to hide my paths in urls?
like maybe

Offline LeoNeeson

  • Tireless poster
  • ****
    • Posts: 740
  • Status: On hiatus (sporadically here)
    • View Profile
Hi! and welcome... :)

What you need, was an idea that I had on my mind several months ago, consisting of sharing files through a macro-generated link (to avoid direct access to files, in case a URL is shared on public without our consent). This should work the same as most file sharing websites work (like mediafire, 1fichier, zippyshare, etc).

For example, we could design something like the following, on 2-steps.

1st) We could generate a public (but unlisted) URL like:
(where "DF9387F890FC72EC563C89BAA34F69B1" could be a MD5 hash-alike of the file, or another kind of hash that points to the real file location on the server). And this should be the link that we could privately share (and we could also add the number of times that this file could be downloaded).

2nd) From the address above, we could then generate a "temporal" direct-link that start a download from:
(where "B203A10D" is another temporal hash that always change, that could be a CRC32 hash, based on the time-stamp+IP-address, and that direct link could be only be valid for 12 hours, and only for that IP address).

Since HFS doesn't have a database to store those "hashes", we could store it on TXT files (where the hash could be the filename), and those TXT should be only be accessed utilizing "macros" (to avoid someone downloading the whole folder with those hashes). Inside those TXT files, we could store the real path to the file, which could be only accessed utilizing "macros" (from the 2nd step mentioned above).

How we could generate the URL from the 1st step? Well, the admin of the server should have a special page (only accessible from localhost), that generate those "hashed-links". Then, there should be another public page (on root) that process the "hashed-links" (converting the hash from the 1st step, on the download link of the 2nd step).

I don't know if it is possible, but, instead of (the admin) having to manually add files on HFS (via drag-and-drop or other way), it would be perfect if we files could be only accessed utilizing "macros", without having to add files or folders into HFS (I mean, without having to have a real or virtual folder/files). This way, the is no way that someone who has the full path of the file, could download the file. This means, downloads only through macros.

Well, that's the idea I have on my mind. The complex part is turning this idea "on a real working template". I didn't have the time yet (and mostly the enough macro knowledge) to do it, but I leave the idea open here, just in case anyone (expert on HFS's macros) want to take this idea. ;)

HFS in Spanish (HFS en Español) / How to compile HFS (Tutorial)
» Currently taking a break, until HFS v2.4 get his stable version.

Offline Tsuna

  • Occasional poster
  • *
    • Posts: 9
    • View Profile
Or we could base64(not a nice solution tbh) but seems like a dirty hack could do.
At the moment the only thing stopping me from using hfs is that the urls are visible clean.