rejetto forum
Software => HFS ~ HTTP File Server => Topic started by: Decode on January 12, 2007, 05:49:14 PM
-
Hello, just want to say i love your software. I want to use HFS to serve public files without need to use login. Now i got big problem as there are newbies who steal my bw as hotlinkin to big files on my server. Im sorry for bad english. I did try to find answe on faq and forum but not got any luck.
-
so you want people to not link to your HFS?
if yes, it is a non-easy problem. first, because HFS has no option about this kind of thing yet (the name is "referrers"). second, because there is no method 100% safe about it, a smart browser (like Opera) can always disable referrer.
-
... a smart browser (like Opera) can always disable referrer.
and don't forget good ol' Proxomitron!
You could set a password on your directories eventually a public one like guest:guest, but then you should disable the user:pass@yourserver/hotlink command option. Hotlinkers then would be annoyed by the login pop-ups ;D and will be forced to link to your entry page.
OT@ Rejetto: I found somewhere in the HFS sources main.pas that the referrer is handled one way or the other, can this referer logged in the Apache format logs, could not find out how-to?
It's already there, did not see it because i,ve disabled referer in my browser ::)
-
you can't "disable" user:pass thing. it's up to the browser.
the browser won't pass it inside the URL, but will move it automatically inside HTTP header related commands.
BUT.... explorer doesn't support it, so all those guys using IE will see the popup anyway ;)
i guess you were confusing with the option inside HFS to automatically put the user:pass in the page.
-
you can't "disable" user:pass thing. it's up to the browser.
...
i guess you were confusing with the option inside HFS to automatically put the user:pass in the page.
Yes, this is what i meant. So, does HFS except accept user:pass@ if this option is disabled, what it should not IMHO, or did i get your answer wrong?
-
i guess "except" is a typo for "accept".
anyway: yes, that's it.
but you misunderstood, there is no way for HFS to tell if the user:pass was passed inside the URL or with the dialog. it is something that has to do with the browser GUI only, the http request is just the same.
-
I thought this issue
http://www.rejetto.com/forum/index.php?topic=3797.msg1018716#msg1018716
http://www.rejetto.com/forum/index.php?topic=3621.0
has been solved some time ago, but apparently not. :o
Why not If URI of httprequest(GET, POST,...) contains user:pass@, then "Request not supported blah" or chop{user:pass@}, else preceed in case that menu URL encoding include password (for DL managers) is disabled?
-
the text you extracted from the RFC is talking about user agents.... also called web browsers.
you may have thought it was talking about servers.
you are not paying enough attention reading what i wrote you in previous post. if you don't believe, try using a sniffer and see yourself.
-
I got your point!
Final question, if you don't mind: Why support a deprecated, insecure UA-request?
-
again: you don't pay enough attention reading what i wrote you in previous post. it is a quite short message, but i will quote you the piece you are missing:
there is no way for HFS to tell if the user:pass was passed inside the URL or with the dialog
maybe you don't know that in english "tell" has also the meaning "distinguish", this may explain the misunderstanding.
-
Thank you for your patience. 100% convinced now. You are right, i did not read well & didn't do my homework right.
:)
-
Well, some sites check the referer of the site the user has come from to prevent hotlinking.
Maybe an option 'Prevent hotlinking' which, for each GET request for a file, checks the referer of the site the user has come from, and if it's not within the same domain, redirects to the main page. Of course this would force all users to enable referers. But, if security and bandwith matter, that would be useful.
MarkV
-
if you search referrer in the to-do-list you'll see it was already "in the air". ;)
anyway yes, feature accepted.