Error while uploading file in filebrowser

[plaban...@gmail.com]

When I am uploading a file into the media library . I am getting an
HTTP error.

Any help with that. Is it a permission issue or something

[Christian Bahls (Gmail)]

had a similar problem, but can also not specify more context

 as it is not really clear where that error came from

 (also not running the server not in developer mode any longer

  but could start an additional to trace that error) [¹]

yours

  Christian

PS: is there a away to do the upload functionality without using a flash plugin?

http://stackoverflow.com/questions/4750168/fileupload-with-django

http://embrangler.com/2010/08/ajax-uploads-images-in-django/

[¹] just wasn't important enough .. the form file upload works so it is only an issue for newly created content on pages

--
I moved away from Google Mail - please use my qb352.de email address

see http://bit.ly/y4vCXB, http://bit.ly/y9invu, http://bit.ly/xyA9vk

and http://bit.ly/AmIiIm 

[Josh Cartmell]

Is it on all uploads or just uploads of a certain size?  I had a site that was using fastcgi that would crash on uploads above a certain size because of a fastcgi timeout setting.

[Stephen McDonald]

Have you used your browser's developer tools for viewing JavaScript errors or failed HTTP requests?

Are you able to upload the file to the demo site? If not, then great, we can replicate it - can you then make the file available somewhere for others to troubleshoot? 

Not much anyone can do otherwise without any info to work with.

--
Stephen McDonald
http://jupo.org

[plaban nayak]

Hi,

when I am visiting the site http://mezzanine.jupo.org/admin/media-library/browse/  I am getting an UnicodeDecodeError.

In my system nginx log the post request to /admin/media_library/upload_file/ shows 403 status and the flash player is Shock wave flash.

In the admin panel after the file is uploaded it shows HTTP Error and then redirects back to the library.

Is there a way i can see what is the error happening.

It happens with files of every size, small and large.

Plaban

[Stephen McDonald]

Thanks Plaban - I think you'll find the uploads directory (project/static/media/uploads/ by default) isn't writeable by the web server user.

The demo site should also work again now.

[plaban nayak]

Hi

What should I do on my system?

Plaban

[plaban nayak]

Ok got it .

[plaban nayak]

I made the home directory and all of its subdirectory   writeable by everyone but still i am getting the same error.

Plaban

[Stephen McDonald]

Have you tried running everything without a web server, using Django's built-in development server?

At least that way you can isolate whether it's a web server issue.

[Stephen McDonald]

I can't reproduce this, but I can point you to what's going wrong.

- The upload view/template passes the current user's session key as a variable when uploading a file via the Flash widget

- The Flash widget posts to the _upload_file view which is wrapped in a flash_login_required decorator

- The flash_login_required decorator checks for the session key, and looks up the user based on session key, which is where the error occurs for you

So something's getting lost in that chain, here are the relevant bits of code:

Session key gets passed to the upload view for using in JS: https://github.com/stephenmcd/filebrowser-safe/blob/master/filebrowser_safe/views.py#L241

Session key gets set in JS for the Flash widget in the upload template: https://github.com/stephenmcd/filebrowser-safe/blob/master/filebrowser_safe/templates/filebrowser/upload.html#L33

Actual upload view that the file is posted to is wrapped in the flash_login_required decorator: https://github.com/stephenmcd/filebrowser-safe/blob/master/filebrowser_safe/views.py#L275

User lookup in the decorator where the error seems to occur: https://github.com/stephenmcd/filebrowser-safe/blob/master/filebrowser_safe/decorators.py#L24

On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henri...@gmail.com> wrote:

Hello,

Same upload problem here:

 * latest version of Mezzanine (1.2.4), deployed with the bundled fabric file, on a newly installed Ubuntu 12.04 server

 * works ok if I start the development server behind nginx

 * doesn't work if I start django with gunicorn (manually or through supervisor)

The exact message is "KeyError at /admin/media-library/upload_file/ :  '_auth_user_id'"

It appears to come from the function _upload_file, in filebrowser_safe/views.py

I had to add logging in django settings to see this.

Any help would be appreciated !

Thanks

Henri

[Henri Colas]

Thanks for the fast answer !

I'll look into it in the next few days, especially the influence of the settings I changed, and report to you if I find something interesting.

Henri

[Henri Colas]

OK, I found what's wrong, and a possible fix:

TL;DR : upload over https doesn't work due to bad redirections, fix is add another prefix to SSL_FORCE_URL_PREFIXES .

----------

With the settings:

+SSL_ENABLED = True

-#SSL_ENABLED = True

+SSL_FORCE_URL_PREFIXES = ("/admin", "/account")

-#SSL_FORCE_URL_PREFIXES = ("/admin", "/account")

     # Uncomment the following if using any of the SSL settings:

+    "mezzanine.core.middleware.SSLRedirectMiddleware",

-    #"mezzanine.core.middleware.SSLRedirectMiddleware",

After investigation, the chain of events is:

GET 'https://mydomain/asset_proxy/?u=/static/filebrowser/uploadify/uploadify.swf' => 302 to same url in HTTP

GET 'http://mydomain/asset_proxy/?u=/static/filebrowser/uploadify/uploadify.swf'

POST http://mydomain/admin/media-library/upload_file/ => 302 to same url in HTTPS

GET https://mydomain/admin/media-library/upload_file/ => error 500 (the one I initially mentionned)

Fix:

If I add "/asset_proxy" to SSL_FORCE_URL_PREFIXES, upload works correctly in https.

But I have no idea of possible consequences !

Henri

[Henri Colas]

Well, it appears that "/asset_proxy" shouldn't always be in HTTPS, so I am reverting to another config:

SSL_FORCE_URL_PREFIXES = ("/account",) 

Henri

[Stephen McDonald]

I suspect that it should use the same protocol as whatever the admin is using.

I was thinking that this is definitely an issue and that there should be some handling (not sure where) that says if SSL is configured, and the admin is forced to use it, then the asset_proxy URL should also do the same.

But now you're saying that's not the case?

[Henri Colas]

On Mon, Oct 1, 2012 at 3:31 AM, Stephen McDonald <st...@jupo.org> wrote:

I suspect that it should use the same protocol as whatever the admin is using.

That's what I think too, but asset_proxy is used in other places, for instance when editing the content of an article directly from the site, not from the admin, it calls the url http://mydomain/asset_proxy/?u=http://mydomain/static/grappelli/tinymce/jscripts/tiny_mce/themes/advanced/source_editor.htm for html editing.

If asset_proxy is set to be redirected to https, this request gets a 302 response, and the redirection gives a 200 response without any content  => the html source editor no longer works..

Same thing for direct image import/editing with the url http://mydomain/asset_proxy/?u=http://mydomain/static/grappelli/tinymce/jscripts/tiny_mce/plugins/advimage/image.htm

[Stephen McDonald]

Good point.

So the correct fix might be to exclude asset_proxy entirely from any redirects within the SSL middleware, allowing it to run on whatever protocol is being used in the page that references it.

Does that sound right? 

[Josh Cartmell]

That makes sense to me.  Awhile back (when ssl handling was still in cartridge) I updated the ssl middleware to look at an additional setting.  URL prefixes in that setting would be served over whatever protocol they were requested on.  Those changes are here:
https://bitbucket.org/joshcartme/cartridge_https-by-url-prefix/changeset/ee35ebeb0819a4dc257983e945d03a5fee0aea69

That change didn't make it into cartridge, but would something like this make sense at this point?  That way if anything else comes up that should be accessible over either protocol it would be as easy as updating a setting.  It could also give users the power to create urls in their own projects that would be accessible over either protocol.

[Stephen McDonald]

Kinda related - yesterday I added a new setting that allows you to disable redirecting back to HTTP when URLs that aren't marked as requiring SSL are accessed over SSL:

https://github.com/stephenmcd/mezzanine/commit/ae111f629a1000e33680d6a02199b759a6611c65

Seems like that might cover the same scenario.

[zgohr]

Just adding this here if someone stumbles upon this thread in the future. File uploads do work over SSL, they just require a valid SSL certificate which can be garnered for free from http://www.startssl.com/