rejetto forum

Software => HFS ~ HTTP File Server => Topic started by: rejetto on August 26, 2007, 03:55:24 PM

Title: not browsable, then hidden ?
Post by: rejetto on August 26, 2007, 03:55:24 PM
what the purpose on showing the folder but we cant enter it? why dont set if the folder is not browsable, it also will be hidden.

this objection makes sense.
i think from now on, when "browsable" is removed from a folder, it should be also considered hidden.
is anyone contrary?
Title: Re: not browsable, then hidden ?
Post by: Giant Eagle on August 26, 2007, 04:27:34 PM
Yes, i think it should display the contents of [protected], which should be a lock image.

So you still know it's there, but.. well.. not accessable :P
Title: Re: not browsable, then hidden ?
Post by: fabnos on August 26, 2007, 04:39:28 PM
Yes, i think it should display the contents of [protected], which should be a lock image.

So you still know it's there, but.. well.. not accessable :P

With which purpose ?

HFS admin know existence of any resources from HFS's vfs and in this way any (users or anonymous) don't have the possibility to see this level.

f.
Title: Re: not browsable, then hidden ?
Post by: TSG on August 26, 2007, 04:41:17 PM
Im with Giant Eagle on this one, it should appear locked.
Title: Re: not browsable, then hidden ?
Post by: fabnos on August 26, 2007, 04:46:51 PM
Im with Giant Eagle on this one, it should appear locked.

For me it's indifferent but, sorry here I'm repeating, why  ???

There is some particular reason that should appear locked ?

f.
Title: Re: not browsable, then hidden ?
Post by: rejetto on August 26, 2007, 04:50:02 PM
this way people would think they need a password. wouldn't they?
Title: Re: not browsable, then hidden ?
Post by: TSG on August 26, 2007, 04:57:27 PM
Good Point...
Title: Re: not browsable, then hidden ?
Post by: TCube on August 26, 2007, 05:01:21 PM
Quote from: fabnos
With which purpose ?
HFS admin know existence of any resources from HFS's vfs and in this way any (users or anonymous) don't have the possibility to see this level.
f.

Well, on the end user side I would like to see who's "active" on Hfs ... that whould trigger my interest to register. Then, it would be up to any user/or user group to accept someone else to "join in"
So i would say : display the protected contents.

TCube
Title: Re: not browsable, then hidden ?
Post by: Giant Eagle on August 26, 2007, 05:01:54 PM
this way people would think they need a password. wouldn't they?

Meaning they wont try to access it, cause they dont know the password. :)

This affects logged-in users aswell, if their account would have given them permission, the lock wouldnt be there in the first place.

Its just an unlock-able lock.


And even so, if they do try to access it.. "What's behind door #1?" "A shiny 'ACCESS DENIED' error page!"

//edit:

Quote from: fabnos
With which purpose ?
HFS admin know existence of any resources from HFS's vfs and in this way any (users or anonymous) don't have the possibility to see this level.
f.

A real HFS Admin knows that there is an option called "Right click folder -> Hide"
Title: Re: not browsable, then hidden ?
Post by: rejetto on August 26, 2007, 05:21:32 PM
Well, on the end user side I would like to see who's "active" on Hfs ... that whould trigger my interest to register. Then, it would be up to any user/or user group to accept someone else to "join in"
So i would say : display the protected contents.

you didn't understand. this has nothing to do with accounts.
when you remove browsable
1. you can still download files if you know their URL
2. no one can see the list, doesn't matter if you have an account
Title: Re: not browsable, then hidden ?
Post by: rejetto on August 26, 2007, 05:24:17 PM
Meaning they wont try to access it, cause they dont know the password. :)

if they should not even try, why should they know it exists?

Quote
A real HFS Admin knows that there is an option called "Right click folder -> Hide"

the point is: is people, EVERY time they click on browsable, clicking ALSO on "hide"?
if the answer is "yes", then there's no sense in having to click twice, it is just extra work.
Title: Re: not browsable, then hidden ?
Post by: fabnos on August 26, 2007, 05:24:45 PM
Quote
Meaning they wont try to access it, cause they dont know the password. :)

This affects logged-in users aswell, if their account would have given them permission, the lock wouldnt be there in the first place.

Its just an unlock-able lock .

And even so, if they do try to access it.. "What's behind door #1?" "A shiny 'ACCESS DENIED' error page!"

Well, as usual I'm thinking in a commercial way (level permissions: Groups and User, etc.)

This way we stimulate the curiosity of the consumers that see the presence of a protected item  :o what treasure there will be inside   ???
and not even users are good clients  >:(

Why not have both possibilities ?
Webmaster can choose which it's better for him in respect of the necessity .

Quote
A real HFS Admin knows that there is an option called "Right click folder -> Hide"

This was obvious   :)  but, indeed, I'm not a real HFS Admin  :P
Title: Re: not browsable, then hidden ?
Post by: TCube on August 26, 2007, 05:35:05 PM
Well, on the end user side I would like to see who's "active" on Hfs ... that whould trigger my interest to register. Then, it would be up to any user/or user group to accept someone else to "join in"
So i would say : display the protected contents.

you didn't understand. this has nothing to do with accounts.
when you remove browsable
1. you can still download files if you know their URL
2. no one can see the list, doesn't matter if you have an account

I did understand myself quite right  ;) .... so fix it as I wish Rejetto ! on the double !  (http://xs118.xs.to/xs118/07340/dmlol.gif) (http://xs.to)

--->

Edit : Fabnos is my friend ! good thinking pal !
Title: Re: not browsable, then hidden ?
Post by: Giant Eagle on August 26, 2007, 06:03:55 PM
Quote
A real HFS Admin knows that there is an option called "Right click folder -> Hide"

the point is: is people, EVERY time they click on browsable, clicking ALSO on "hide"?

Heh :P you actually make it sound like we daily add thousends of folders and want to hide them and make them not browseable, because i dont see your point otherwise. It's a server. A server needs time to set up properly. Dont have time? Dont start a server.

Quote
if the answer is "yes", then there's no sense in having to click twice, it is just extra work.

>_< What do you win by this? 0.6 seconds?

If you really want to decrease "work-time" or "Annoyance", then create a menu that does not go away when you select something. Give it select boxes and those "Apply" "Cancel" and  "Ok" buttons like most setting menu's have. I'm sure people prefer this over the 'Browsable feature auto-hiding the selected folder if checked' thing.

just my opinion, no offence at all..
Title: Re: not browsable, then hidden ?
Post by: rejetto on August 26, 2007, 11:39:21 PM
Quote
if the answer is "yes", then there's no sense in having to click twice, it is just extra work.

>_< What do you win by this? 0.6 seconds?

it was not meant to save the time for the click.
the extra work is for complexity.
to get things easier.
10 seconds is a short time, but if you have to spend it thinking & searching, you will feel the thing as "not that clear and easy".

anyway, i don't see an agreement on this matter.
we can just leave things as they are.

and, an advice: if you want to see the [locked] on the folder, set also a password.
that's not the same thing, but may be good for someone.
Title: Re: not browsable, then hidden ?
Post by: radd on August 27, 2007, 02:41:03 AM
yes rejetto, i dont think u need to change anything. i dont like the browsable so i dont use it, i use hidden. but someone else might like to use it. eventhough new user might be little confuse on the browsable, why it should show if cant access - finally i think they will just use hidden. so no prob at all
thanks for ur care
Title: Re: not browsable, then hidden ?
Post by: MarkV on August 27, 2007, 06:42:58 PM
I think we should leave things as they are. What if you want a browsable folder inside a not browsable one. Then you should at least see this subfolder (At the moment you see error). Why not simply show an empty listing with the text <folder listing disabled>? In this case, even the Upload button would stay accessible.

You could integrate an 'internal' folder diff template to accomplish this.
Title: Re: not browsable, then hidden ?
Post by: TSG on August 28, 2007, 07:26:45 AM
Well now.. >_> didn't this thread flare up... http://www.rejetto.com/forum/index.php?topic=4735.msg1026224#msg1026224

That link above, is a post where fabnos came across a folder a small time ago while testing on my server.

I have made the ToG folder on my server 'non-browseable' because it has a lot of top secret files in it at this time :o.

He found that the folder APPEARED to be accessible, but when he clicked on the link HFS fed back the [deny] page, read his post and you will see how it went down.

A solution, i cannot suggest...

I like the fact it feeds back Access Denied. BUT i also don't like the fact the resource appears accessible but isn't, quite a quandary isn't it.

Do we make Browseable continue to do what it currently does? do we make it hide the folder? or do we do some other unforeseen solution.... personally, i'd prefer it to appear locked and when you click on the link, it feeds back the Access Denied page, unlike a protected resource that feeds back Unauthorised.

I hope this helps in some way..

Title: Re: not browsable, then hidden ?
Post by: Foggy on August 28, 2007, 08:24:15 AM
i'd prefer it to appear locked and when you click on the link, it feeds back the Access Denied page, unlike a protected resource that feeds back Unauthorised.

I agree with TSG because you can always select to hide it.
Title: Re: not browsable, then hidden ?
Post by: maverick on August 28, 2007, 09:15:42 AM

I agree with radd - "i dont think u need to change anything".

I agree with MarkV - "I think we should leave things as they are".

I agree with rejetto - "we can just leave things as they are".

Everything is working just fine.  No sense fixing something that doesn't need to be fixed.