SvManager's own security system is designed to keep unauthorised people out of the admin functions but let everyone view the galleries. I can't think of an easy way to create what is in effect a permissions system with two different levels of access – admin and view – and two different passwords.

However, here are a few thoughts that might help.

The way the upload process works is this. The java applet uploads the images into the server's default temporary directory. It then calls a php script (myupload.php) that runs a few checks on the image files and then copies the images into a folder inside your gallery. I guess this script was hitting your password protection. The script will be running under your web user.

I'm not an expert on .htaccess but would it be possible to modify the .htaccess file to grant the web user access as well as your authorised users while keeping everyone else out?

jack

The java applet uploads to the server's default temp directory, set by the server itself. This would not be inside the svmanager directory. The uploaded files are then copied to the appropriate gallery directory, for instance svmanager/g1/images.

So I would double-check that it's not some permissions problem with the default temp directory

It might also be worth checking the setting of the upload_tmp_dir directive in your php.ini file (normally set to null) although I don't think this value affects the java applet.

However I'd guess that the real problem is happening when the php script tries to copy the files from the server temp directory to the gallery directory and it hits your security system.

jack

If you have used the svManager import screen to import your external gallery or if you have created a gallery in svManager and then moved it by changing the path on the customize screen then svManager will know where to find it. It should copy uploaded files directly from your temp directory to the images subdirectory of your gallery directory.

jack

I'm pretty bummed about this; a lot of attacks nowadays are being done robotically and are either brute-force or attacking specific vulnerabilities in code.

While I'm pretty confident I can set up a reliable password using .htaccess, and lock it down to my specific host, now I'm stuck with basically having to trust svmanager's security system - something I am highly disinclined to do with PHP code. It's really a bad bad bad bad bad (did I say "bad" enough times?) idea to code so that you're defeating other security systems. I've seen hundreds of programmers who thought they could get it right and didn't. :(

Just for example, if I could put my .htaccess file in front of svmanager, it'd be possible for me to hide the fact that it's svmanager running in that directory. That'd be a huge win because (as I said earlier) the usual modus hack is to find a vuln in something and just start scanning www-whatever for that app. If there's a vuln found in svmanager, we're all toast in 24 hours.

This is a major mis-feature. Bleh.