Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Uploading files without a file input box 1

Status
Not open for further replies.

MichaelHooker

Programmer
Mar 17, 2006
70
GB
I use html and php, with IE7. Every example for uploading files I have seen uses a form with an input type of "file" and a submit button.

I have used this and it works well, but it adds an unnecessary stage to my work-flow. The name of the jpg file to be uploaded and the path to it are already contained in a php variable, indeed the former has just been added to a MySQL table with other details about the photo. All I need is, once I have read back the new table entry to check the details, a button to confirm "Yes, that's OK, now upload the file that it relates to".

I have not been able to find any way of programmatically assigning a value to a file-type input box like you can other inputs. I've read that there is no way of avoiding having to browse for the file "unless the browser has allowed local file access via a decreased security setting". Fair enough to limit unauthorised uploads from my computer by other people I suppose, but I can't see any setting in IE7 relating to local file access anyway.

So, do I give up or does anyone know a nifty way around this problem please?

Thanks in advance

Michael Hooker
 
I don't think this can be done. The security is about only uploading a file which the visitor allows access to. To the visitor's browser, your vars in PHP and MySQL are just meaningless characters.
When a download is initiated, your server creates a file variable which at that point has no value, the visitors browser gives that var a value and passes it back to your server. Your server is then able to access tghe file directly.
From a design point of view it would be useful to have the functionality you require, from a security point of view, it would be a very dangerous thing.

Keith
 
Thanks, that's the conclusion I've come to, but there may have been another approach to the whole problem.

Talking of very dangerous things, the commercial hoster of my shared server makes it very difficult to secure anything. They do provide what they call a private folder in which they suggest I store sensitive information such as passwords, email addresses etc, but there is no way to access it (that they will tell me about) other than FTP using my username/password. So it's pretty useless, except perhaps to keep a backup copy of the rest of the site. The best I can do is keep things in the MySQL database, but any page that needs to include the php login script is going to give away where the script is, however well-hidden, and the script will inevitably contain access details to the database. At the moment my "administration" pages are secured by me typing in a username/password which correspond to cookies read from my PC, and the values of the cookies aren't stored anywhere on the server. After running the page that set the cookies, I deleted it, and can always upload it again when the cookies expire or I feel like giving them new values. I admit my site is simply a set of 7000+ aircraft photos which anyone can download if they want and is unlikely to attract anyone hoping to find something they can profit from, but I would like a bit of protection from internet vandals with nothing better to do!

Michael Hooker
 
You would normally access your 'private' folder from within a server side script, be it PHP, Perl etc. Your script should be protected by folder permissions to prevent anyone from outside reading the contents. That is the minimum security expectation from any ISP.

Keith
 
any page that needs to include the php login script is going to give away where the script is, however well-hidden, and the script will inevitably contain access details to the database.
You're missing a point about php scripts work. That's understandable, because you generally interlace php code with html and it looks a bit like javascript, but it's fundamentally different: php is a server-side language.

Your php is executed on the server, not in the browser like javascript is. So if an attacker does a "view source" on a php page, (s)he doesn't see the php code, (s)he sees the html that the php generates.

That's also where the private directory comes in. Your php scripts can access it, because they're on the server so it's just another directory to them, but attackers can't access it accross the web (assuming they were somehow able to find out the file name to look for). Personally, I always create a "secure" directory for all my sites - not web-accessible, but containing all the files my scripts need to play with.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
You may not be able to rid yourself from selecting the file, but the rest of the process could be reduced. For example, it may be helpful to know that you can make nearly anything on a webpage (a div, an image, etc) clickable so that it will open a File Dialog. Then when the user selects the file, you can have it instantly uplaod the file ajax style so the page never has to reload.

I've done this sort of thing using the jquery javascript library. I'm not sure if you are familiar with jquery, but here is a sample plugin of what I described in action:


Hope this helps,
Adam

- The fastest way to snag your tickets.
 
On the private folder point:

you will have to forgive me for believing what my server host's helpdesk told me. I asked specifically if I could put my MySQL login script in the private folder, to be "include"-d in other php scripts in the main "htdocs" folder on the fly, and they said "No". They also said that all other hosting services operated the same policy.

I have been back to them, and now they say it will work if I use the correct pathname. Of course, they didn't tell me what the correct pathname should be! It really is like wading through treacle, in the dark, and with only a foam rubber spear to feel for obstacles, corresponding with these people. I should have guessed that the one time they have ever given me a straight answer, it was wrong.

The site as seen from an FTP client has the folders:
/htdocs (and lots of subfolders of my creation)
/logfiles
/private

I'm guessing that only a relative path will do, because the normal full URL to the site eg leads straight to /htdocs. MyWebSite.com/index.htm is what I see as /htdocs/index.htm. So the path from a script in htdocs would, I hope, be ../private/mysecrets.php and the path from a sub-folder of htdocs (in the real world now) would be ../../private/mysecrets.php. I shall go and try it out.

Thanks to Crazy888s for the advice on uploading files. I don't mind the extra click, it's navigating the file system for the image to be uploaded that is the real problem. There are 75,000 files to pick from, not even all on the same HDD. Some of the folders have thousands of files in them. Many of the files have very similar filenames. I have named the folders so that it is programmatically possible to assemble a full pathname given the date and place the photograph was taken, and the identity of the subject aircraft which is used as the actual jpg filename. so it is a no-brainer finding and loading them in my Delphi programs, just by clicking a line in the database that holds these details. I don't bother to waste disk space on storing the full path in the database for each entry. But that's on my desktop PC. I think you can see why I was hoping to do much the same thing when uploading them to my website!

Thanks again

Michael Hooker
 
As an aside, you might find that remembering how many folder levels to traverse from any arbitrary page is going to be annoying. More so, if you ever refactor your site and change the structure.

One small snippet I use to always include a file at the root level of my site, no mater where the initial page is, is:

Code:
<?
	$TEMP_levels_deep = count(explode("/", trim($_SERVER["SCRIPT_NAME"]))) - 2;
	$TEMP_path = "";
	for ($loop = 0; $loop < $TEMP_levels_deep; $loop++) $TEMP_path .= "../";
	include $TEMP_path . "FILE_AT_ROOT.php";
?>

This way, you never have to worry about moving files or folders around.

You might need to tweak some of those things (e.g. -2, '../', etc) for your hosting setup, but after that, things should work perfectly. If you've any queries with that script, you should probably ask in forum434, though.

Hope this helps,
Dan




Coedit Limited - Delivering standards compliant, accessible web solutions

Dan's Page [blue]@[/blue] Code Couch:
Code Couch Tech Snippets & Info:
 
Thanks to Billy Ray Son of a Preacher Man: setting a variable for long and complicated paths is something I usually do to avoid mistyping when they are repeated a lot, creating them programmatically is even better. I agree we're moving away from the remit of this forum.

The path "../../private/mysecrets.php" worked like a dream, first time, and I've been busy tracking down all the scripts that refer to the old location and changing them.

Going back to php scripts being "invisible", I do understand the points about reading the page source and not seeing the script, just the html. But there are other ways of skinning a cat if you know them and the suggestion I have read that you should turn your scripts into bytecode to obfuscate them suggests that it can't be so difficult to access php scripts. Still, that's for the php forum.

Michael Hooker
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top