By default, the File Browser connector will access the file system under whatever credentials the application pool is configured to use, e.g., on a straightforward w2k3 installation, you will need to set up a modify ACL for the 'NETWORK SERVICE' user.
Using my mod and setting UseImpersonation to true in config.ascx, all file system access impersonates the identity of the client. Thus, using anonymous access, the ISUR_<computername> user will need those permissions - no big improvement. However, one now can configure the site to use Windows integrated authentication, and assign appropriate rights to the actual users or domain groups. Neither 'NETWORK SERVICE' nor ISUR_<computername> should have any ACL entries on the UserFilesAbsolutePath folder under such a configuration.
Note this is not restricted to work seamlessly with IE only. Firefox will handle NTLM authentication quite well, but you must explicitly tell it to do so: Open about:config, type 'ntlm' into the filter, turn on network.ntlm.send-lm-response, and add your server name to network.automatic-ntlm-auth.trusted-uris (which is a comma-separated list).
As this is indended for intranet use, Exception handling has not been subjected to sufficient testing. While there is no obvious code path leaving Impersonation open to attack, complex scenarios involving e.g. ThreadAbort have not been considered either.
The helper code used for creating directories has the capability to use the unmmanaged Win32 API when the .net way fails. Unfortunately, this workaround path is used regardless of the nature of the original failure, and the exception that is generated if the _mkdir call fails as well is a generic ApplicationException and does not differentiate between, say, a lack of permissions and other causes.
Setting CreateDirectoryWorkaround to false in config.ascx will disable this, allowing the .net exception to propagate. Together with my other changes, this allows the user to receive a more helpful error message. In my testing, I have not been able to reproduce the failure the workaround was designed for, and this variant performed to expectations in all my tests.
As far as I know there is no variant of English where 'appearence' is the proper spelling for 'appearance'. As this is just a property grouping header in the IDE, I deemed the fix to be safe.
Most controls in the standard asp.net toolbox have a CssClass property, so I added one here, too. It performs as can be expected: As long as it is empty, nothing changes, when it is set, the outer div FCKeditor uses receives that CSS class attribute. The VWD 2008 IDE also applies appropriate checks (like whether the stylesheet actually defines the class).
The new RemoteMessages switch determines if the message property of any exception will be passed to the client. As with ASP RemoteErrors, this should only be turned on for debugging or in trusted environments, as it can potentially lead to unwanted information disclosure. Exception handling in the connector commands has been shuffled around a bit, now most exceptions will be caught and forwarded.
The client error handling has been adapted to match, see below.
The config.ascx file has new code to initialize the new options as described above.
The client error handling has been adapted to the changed ways the asp.net integration forwards exceptions: Commands using a XML response carry the detailed error message in a new 'message' attribute on the 'Error' node and the CheckError function in browser.html now has the capability to display it. This change is transparent enough concerning other file browser connectors.
The new file upload command error handling is not a clean solution - I decided to return a standard http status code for failures with appropriate error text in the body of the response, which is IMHO the correct approach, but the client code did not have existing code to handle this result. In fact, it would just leave the 'working' message on screen, leave the upload button disabled and otherwise not indicate any result. I have added code to react to the result of the postback, and this code checks the body content of the response and reacts appropriately on the surface. However, it does not check the actual http status code as I would have thought appropriate - I guess this would necessitate a real Ajax rewrite. Behaviour with non-aspx connectors I haven't even thought about properly - I'd say it would not change the observed behaviour at all, as the postback of the upload worker frame does not seem to be handled at all in vanilla 2.6.4.1