If you want it to behave that way, then set BaseURL to a script that sends the file instead of getting the URL of the file and then modifying it with the SelectFunction. That way you can even move the files out of the public folders so they are served only by the scripts and you are safer because people won't be able to find a direct URL for the files.
However, it would still be nice to be able to control which items show up in the context menu. Right now, in my implementation, "View" and "Select" do exactly the same thing. I tweaked the source code a bit so that the "View" item calls my script instead of accessing the URL directly. I like your idea about setting the BaseURL better, but that'll still leave both the "View" and "Select" items doing the same thing. I would really like to see some kind of option in the config file that selects which menu items you want visible.
Or, just as good, have the option to have a double-click trigger the "View" action instead of calling a SelectFunction. Since viewing is the most common result of a double-click, that would release the developer from the need to provide a SelectFunction and would also eliminate having a redundant menu item when the developer chooses to implement the common scenario of a double-click View.
The most common action of double clicking is selecting the file in order to insert that image or link into the editor or whatever input you are using for picking files. Full view or download of the files are usually secondary actions, and that's why they are placed in the context menu.
Of course, depending on how you are using CKFinder your needs will be different, in the future it will be possible to control better the toolbar and context menus, including the option to add your own items or hide existing ones.
I finally got around to trying it the way you suggested, setting the BaseUrl to my viewer script, and it's not working. What's happening is that CKFinder is not URLEncoding the URL it opens the new browser with. Therefore the full unencoded URL of the file, with slashes, spaces, and all, is included in the main URL, which is confusing the browser.
Upon further experimentation, it appears as though it is working and my browser was just having trouble with its PDF add-in.
My worry, though, is that even though it works, that's mainly due to browser leniency, and it's still not technically correct. Shouldn't the URL be URLEncoded when you select "View"?
Sadly, in my scenario, that still wouldn't be enough. For example, here is my BaseURL:
BaseUrl = "/owner/showdoc.aspx?file="
The problem here is that for the final URL to be correct in this scenario, the part after the BaseURL has to be encodeURIComponent encoded, because the slashes need to be escaped, since the remainder of the URL is simply a parameter to the main URL. But there is no way for CKFinder to know this with its current configuration scheme. By having simply a "BaseURL" and concatenating the file path to the end of it, the programmer's options are far more limited than if there was a more customizable scheme for mapping file paths to URLs.
Re: Circumventing ACL: "View" context menu item unsafe
Re: Circumventing ACL: "View" context menu item unsafe
However, it would still be nice to be able to control which items show up in the context menu. Right now, in my implementation, "View" and "Select" do exactly the same thing. I tweaked the source code a bit so that the "View" item calls my script instead of accessing the URL directly. I like your idea about setting the BaseURL better, but that'll still leave both the "View" and "Select" items doing the same thing. I would really like to see some kind of option in the config file that selects which menu items you want visible.
Or, just as good, have the option to have a double-click trigger the "View" action instead of calling a SelectFunction. Since viewing is the most common result of a double-click, that would release the developer from the need to provide a SelectFunction and would also eliminate having a redundant menu item when the developer chooses to implement the common scenario of a double-click View.
Thanks again.
Re: Circumventing ACL: "View" context menu item unsafe
Of course, depending on how you are using CKFinder your needs will be different, in the future it will be possible to control better the toolbar and context menus, including the option to add your own items or hide existing ones.
Re: Circumventing ACL: "View" context menu item unsafe
Re: Circumventing ACL: "View" context menu item unsafe
My worry, though, is that even though it works, that's mainly due to browser leniency, and it's still not technically correct. Shouldn't the URL be URLEncoded when you select "View"?
Sadly, in my scenario, that still wouldn't be enough. For example, here is my BaseURL:
BaseUrl = "/owner/showdoc.aspx?file="
The problem here is that for the final URL to be correct in this scenario, the part after the BaseURL has to be encodeURIComponent encoded, because the slashes need to be escaped, since the remainder of the URL is simply a parameter to the main URL. But there is no way for CKFinder to know this with its current configuration scheme. By having simply a "BaseURL" and concatenating the file path to the end of it, the programmer's options are far more limited than if there was a more customizable scheme for mapping file paths to URLs.
Re: Circumventing ACL: "View" context menu item unsafe
add the following rule to "uipanel.css"
.cke_button_viewFile{ visibility:hidden; position:absolute; }http://www.cosifunziona.it/2010/09/22/ckfinder-e-aspnet-come-proteggere-i-contenuti-da-link-diretti-sulle-risorse-statiche/