In flask_uploads.py

Change

from werkzeug import secure_filename,FileStorage

to

from werkzeug.utils import secure_filename
from werkzeug.datastructures import  FileStorage

That exception looks like Flask-Uploads is trying to from werkzeug import secure_filename which should be from werkzeug.utils import secure_filename, as per your own code.

Going by the Flask-Uploads github repo this appears to have been fixed 12 months ago.

I'd try pip install -U flask-uploads in your virtual environment, to ensure the latest version.

EDIT:

As @mattficke points out, the PyPi version is dated, and there's not a more recent release on the repo. Turns out you can install directly based on a commit hash, so for the latest (at the time of writing this):

pip install git+https://github.com/maxcountryman/flask-uploads.git@f66d7dc

Or in a requirements.txt:

git+https://github.com/maxcountryman/flask-uploads.git@f66d7dc

Then pip install -r requirements.txt.

Which works wonders:

>>> from flask_uploads import UploadSet,configure_uploads,IMAGES,DATA,ALL
>>> # No Exception

You are correct.

You only need to use the secure_filename function if you are using the value of request.files['file'].filename to build a filepath destined for your filesystem - for example as an argument to os.path.join.

As you're using a UUID for the filename, the user input value is disregarded anyway.

Even without S3, it would also be safe NOT to use secure_filename if you used a UUID as the filename segment of the filepath on your local filesystem. For example:

uploaded_file = request.files['file']
if uploaded_file:
    file_uuid = uuid.uuid4()
    file.save(os.path.join(app.config['UPLOAD_FOLDER'], file_uuid))
    # Rest of code

In either scenario you'd then store the UUID somewhere in the database. Whether you store the originally provided request.files['file'].filename value alongside that is your choice.

This might make sense if you want the user to see the original name of the file when they uploaded it. In that case it's definitey wise to run the value through secure_filename anyway, so there's never a situation where the frontend displays a listing to a user which includes a file called ../../../../ohdear.txt

the secure_filename docstring also points out some other functionality:

Pass it a filename and it will return a secure version of it. This filename can then safely be stored on a regular file system and passed to :func:os.path.join. The filename returned is an ASCII only string for maximum portability. On windows systems the function also makes sure that the file is not named after one of the special device files.

>>> secure_filename("My cool movie.mov")
'My_cool_movie.mov'
>>> secure_filename("../../../etc/passwd")
'etc_passwd'
>>> secure_filename(u'i contain cool \xfcml\xe4uts.txt')
'i_contain_cool_umlauts.txt'

UPLOAD_FOLDER is not a configuration option recognized by Flask. f.save works relative to the current working directory, which is typically the project root during development.

Join the secured filename to the upload folder, then save to that path.

f.save(os.path.join(app.config['UPLOAD_FOLDER'], secure_filename(f.filename)))

It's better to store local data in the instance folder, not the project root. Flask already knows where that is. Just make sure you create the instance directory first.

import os
from werkzeug.utils import secure_filename

# create the folders when setting up your app
os.makedirs(os.path.join(app.instance_path, 'htmlfi'), exist_ok=True)

# when saving the file
f.save(os.path.join(app.instance_path, 'htmlfi', secure_filename(f.filename)))

No matter where you decide to save it, you need to make sure the user running the application has write permission to that directory. If you get permission errors when running with mod_wsgi, for example, the user is commonly httpd or www-data. If you get a permission denied error, check that.