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) [¹]
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.
On Sat, Apr 7, 2012 at 10:01 AM, Christian Bahls (Gmail) <
christian.ba...@gmail.com> wrote: > 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) [¹]
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.
On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com <
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.
On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org> wrote: > 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.
> On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com < > plaban.na...@gmail.com> wrote:
>> 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
> 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
> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org> wrote:
>> 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.
>> On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com < >> plaban.na...@gmail.com> wrote:
>>> 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
On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org> wrote: > 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.
> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban.na...@gmail.com>wrote:
>> 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
>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org> wrote:
>>> 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.
>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com < >>> plaban.na...@gmail.com> wrote:
>>>> 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
>>> 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
>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org> wrote:
>>>> 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.
>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com < >>>> plaban.na...@gmail.com> wrote:
>>>>> 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
> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban.na...@gmail.com>wrote:
>> Hi
>> What should I do on my system?
>> Plaban
>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org> wrote:
>>> 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.
>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban.na...@gmail.com>wrote:
>>>> 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
>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>> 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.
>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com < >>>>> plaban.na...@gmail.com> wrote:
>>>>>> 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
On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban.na...@gmail.com> wrote: > I made the home directory and all of its subdirectory writeable by > everyone but still i am getting the same error.
> Plaban
> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban.na...@gmail.com>wrote:
>> Ok got it .
>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban.na...@gmail.com>wrote:
>>> Hi
>>> What should I do on my system?
>>> Plaban
>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>> 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.
>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban.na...@gmail.com>wrote:
>>>>> 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
>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>> 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.
>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban.na...@gmail.com < >>>>>> plaban.na...@gmail.com> wrote:
>>>>>>> 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
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:
On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>> 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.
>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com> wrote:
>>> I made the home directory and all of its subdirectory writeable by
>>> everyone but still i am getting the same error.
>>> Plaban
>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>> Ok got it .
>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban...@gmail.com>wrote:
>>>>> Hi
>>>>> What should I do on my system?
>>>>> Plaban
>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>> 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.
>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>> 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
>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>> 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.
>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>> 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
>>>>>>>> --
>>>>>>>> Stephen McDonald
>>>>>>>> http://jupo.org
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.
On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org> wrote:
> 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:
> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>> 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.
>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>> I made the home directory and all of its subdirectory writeable by
>>>> everyone but still i am getting the same error.
>>>> Plaban
>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>> Ok got it .
>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>> Hi
>>>>>> What should I do on my system?
>>>>>> Plaban
>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>> 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.
>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>> 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
>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>>> 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.
>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>> 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
>>>>>>>>> --
>>>>>>>>> Stephen McDonald
>>>>>>>>> http://jupo.org
# Uncomment the following if using any of the SSL settings:
+ "mezzanine.core.middleware.SSLRedirectMiddleware",
- #"mezzanine.core.middleware.SSLRedirectMiddleware",
On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com> wrote:
> 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
> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org> wrote:
>> 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:
>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>> 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.
>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>> I made the home directory and all of its subdirectory writeable by
>>>>> everyone but still i am getting the same error.
>>>>> Plaban
>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>> Ok got it .
>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>> Hi
>>>>>>> What should I do on my system?
>>>>>>> Plaban
>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>> 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.
>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>>> 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
>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>>>> 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.
>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>> 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
>>>>>>>>>> --
>>>>>>>>>> Stephen McDonald
>>>>>>>>>> http://jupo.org
>>>>>>>> --
>>>>>>>> Stephen McDonald
>>>>>>>> http://jupo.org
> # Uncomment the following if using any of the SSL settings:
> + "mezzanine.core.middleware.SSLRedirectMiddleware",
> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
> 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
> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com>wrote:
>> 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
>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org>wrote:
>>> 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:
>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>>> 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.
>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>> I made the home directory and all of its subdirectory writeable by
>>>>>> everyone but still i am getting the same error.
>>>>>> Plaban
>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>> Ok got it .
>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>> Hi
>>>>>>>> What should I do on my system?
>>>>>>>> Plaban
>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>>> 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.
>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>>>> 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
>>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>> 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
>>>>>>>>>>> --
>>>>>>>>>>> Stephen McDonald
>>>>>>>>>>> http://jupo.org
>>>>>>>>> --
>>>>>>>>> Stephen McDonald
>>>>>>>>> http://jupo.org
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.
On Mon, Oct 1, 2012 at 6:18 AM, Henri Colas <henrico...@gmail.com> wrote:
> 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
> On Sat, Sep 29, 2012 at 10:12 AM, Henri Colas <henrico...@gmail.com>wrote:
>> 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
>> # Uncomment the following if using any of the SSL settings:
>> + "mezzanine.core.middleware.SSLRedirectMiddleware",
>> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
>> 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
>> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com>wrote:
>>> 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
>>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org>wrote:
>>>> 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:
>>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>>>> 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.
>>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>> I made the home directory and all of its subdirectory writeable
>>>>>>> by everyone but still i am getting the same error.
>>>>>>> Plaban
>>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>> Ok got it .
>>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>>> Hi
>>>>>>>>> What should I do on my system?
>>>>>>>>> Plaban
>>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>>>> 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.
>>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <plaban...@gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>> 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
>>>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <st...@jupo.org
>>>>>>>>>>> > wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>> 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
>>>>>>>>>>>> --
>>>>>>>>>>>> Stephen McDonald
>>>>>>>>>>>> http://jupo.org
>>>>>>>>>> --
>>>>>>>>>> Stephen McDonald
>>>>>>>>>> http://jupo.org
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.
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..
> 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?
> On Mon, Oct 1, 2012 at 6:18 AM, Henri Colas <henrico...@gmail.com> wrote:
>> 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
>> On Sat, Sep 29, 2012 at 10:12 AM, Henri Colas <henrico...@gmail.com>wrote:
>>> 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
>>> # Uncomment the following if using any of the SSL settings:
>>> + "mezzanine.core.middleware.SSLRedirectMiddleware",
>>> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
>>> 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
>>> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com>wrote:
>>>> 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
>>>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org>wrote:
>>>>> 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:
>>>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>>>>> 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.
>>>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>> I made the home directory and all of its subdirectory writeable
>>>>>>>> by everyone but still i am getting the same error.
>>>>>>>> Plaban
>>>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>>> Ok got it .
>>>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <plaban...@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>> Hi
>>>>>>>>>> What should I do on my system?
>>>>>>>>>> Plaban
>>>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <st...@jupo.org
>>>>>>>>>> > wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <
>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>> 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
>>>>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <
>>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Stephen McDonald
>>>>>>>>>>>>> http://jupo.org
>>>>>>>>>>> --
>>>>>>>>>>> Stephen McDonald
>>>>>>>>>>> http://jupo.org
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.
> 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..
>> 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?
>> On Mon, Oct 1, 2012 at 6:18 AM, Henri Colas <henrico...@gmail.com> wrote:
>>> 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
>>> On Sat, Sep 29, 2012 at 10:12 AM, Henri Colas <henrico...@gmail.com>wrote:
>>>> 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
>>>> # Uncomment the following if using any of the SSL settings:
>>>> + "mezzanine.core.middleware.SSLRedirectMiddleware",
>>>> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
>>>> 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
>>>> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com>wrote:
>>>>> 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
>>>>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>> 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:
>>>>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>>>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>>>>>> 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.
>>>>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>>> I made the home directory and all of its subdirectory writeable
>>>>>>>>> by everyone but still i am getting the same error.
>>>>>>>>> Plaban
>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <plaban...@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>> Ok got it .
>>>>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <
>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>> Hi
>>>>>>>>>>> What should I do on my system?
>>>>>>>>>>> Plaban
>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <
>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <
>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <
>>>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Stephen McDonald
>>>>>>>>>>>>>> http://jupo.org
>>>>>>>>>>>> --
>>>>>>>>>>>> Stephen McDonald
>>>>>>>>>>>> http://jupo.org
>>>>>>>> --
>>>>>>>> Stephen McDonald
>>>>>>>> http://jupo.org
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/change...
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.
On Mon, Oct 1, 2012 at 2:08 PM, Stephen McDonald <st...@jupo.org> wrote:
> 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?
> On Tue, Oct 2, 2012 at 7:06 AM, Henri Colas <henrico...@gmail.com> wrote:
>> 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.
>> 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..
>>> 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?
>>> On Mon, Oct 1, 2012 at 6:18 AM, Henri Colas <henrico...@gmail.com>wrote:
>>>> 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
>>>> On Sat, Sep 29, 2012 at 10:12 AM, Henri Colas <henrico...@gmail.com>wrote:
>>>>> 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
>>>>> # Uncomment the following if using any of the SSL settings:
>>>>> + "mezzanine.core.middleware.SSLRedirectMiddleware",
>>>>> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
>>>>> 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
>>>>> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com>wrote:
>>>>>> 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
>>>>>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>> 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:
>>>>>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>>>>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>>>>>>> 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.
>>>>>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com>wrote:
>>>>>>>>>> I made the home directory and all of its subdirectory
>>>>>>>>>> writeable by everyone but still i am getting the same error.
>>>>>>>>>> Plaban
>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <
>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>> Ok got it .
>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <
>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>> Hi
>>>>>>>>>>>> What should I do on my system?
>>>>>>>>>>>> Plaban
>>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <
>>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <
>>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <
>>>>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 AM, plaban...@gmail.com <
>>>>>>>>>>>>>>> plaban...@gmail.com> wrote:
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:
On Tue, Oct 2, 2012 at 8:35 AM, Josh Cartmell <joshcar...@gmail.com> wrote:
> 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:
> 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.
> On Mon, Oct 1, 2012 at 2:08 PM, Stephen McDonald <st...@jupo.org> wrote:
>> 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?
>> On Tue, Oct 2, 2012 at 7:06 AM, Henri Colas <henrico...@gmail.com> wrote:
>>> 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.
>>> 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..
>>>> 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?
>>>> On Mon, Oct 1, 2012 at 6:18 AM, Henri Colas <henrico...@gmail.com>wrote:
>>>>> 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
>>>>> On Sat, Sep 29, 2012 at 10:12 AM, Henri Colas <henrico...@gmail.com>wrote:
>>>>>> 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
>>>>>> # Uncomment the following if using any of the SSL settings:
>>>>>> + "mezzanine.core.middleware.SSLRedirectMiddleware",
>>>>>> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
>>>>>> 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
>>>>>> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henrico...@gmail.com>wrote:
>>>>>>> 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
>>>>>>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org>wrote:
>>>>>>>> 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:
>>>>>>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henrico...@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
>>>>>>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a écrit :
>>>>>>>>>> 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.
>>>>>>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <plaban...@gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>> I made the home directory and all of its subdirectory
>>>>>>>>>>> writeable by everyone but still i am getting the same error.
>>>>>>>>>>> Plaban
>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <
>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>> Ok got it .
>>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <
>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>> What should I do on my system?
>>>>>>>>>>>>> Plaban
>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <
>>>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <
>>>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 8:47 AM, Stephen McDonald <
>>>>>>>>>>>>>>> st...@jupo.org> wrote:
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/
On Monday, October 1, 2012 7:48:39 PM UTC-5, Stephen McDonald wrote:
> 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:
> On Tue, Oct 2, 2012 at 8:35 AM, Josh Cartmell <joshc...@gmail.com<javascript:>
> > wrote:
>> 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:
>> 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.
>> On Mon, Oct 1, 2012 at 2:08 PM, Stephen McDonald <st...@jupo.org<javascript:>
>> > wrote:
>>> 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?
>>> On Tue, Oct 2, 2012 at 7:06 AM, Henri Colas <henri...@gmail.com<javascript:>
>>> > wrote:
>>>> On Mon, Oct 1, 2012 at 3:31 AM, Stephen McDonald <st...@jupo.org<javascript:>
>>>> > 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/tinym... 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..
>>>>> 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?
>>>>> On Mon, Oct 1, 2012 at 6:18 AM, Henri Colas <henri...@gmail.com<javascript:>
>>>>> > wrote:
>>>>>> 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
>>>>>> On Sat, Sep 29, 2012 at 10:12 AM, Henri Colas <henri...@gmail.com<javascript:>
>>>>>> > wrote:
>>>>>>> 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
>>>>>>> # Uncomment the following if using any of the SSL settings:
>>>>>>> + "mezzanine.core.middleware.SSLRedirectMiddleware",
>>>>>>> - #"mezzanine.core.middleware.SSLRedirectMiddleware",
>>>>>>> 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
>>>>>>> On Sun, Sep 23, 2012 at 11:28 PM, Henri Colas <henri...@gmail.com<javascript:>
>>>>>>> > wrote:
>>>>>>>> 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
>>>>>>>> On Sun, Sep 23, 2012 at 11:21 PM, Stephen McDonald <st...@jupo.org<javascript:>
>>>>>>>> > wrote:
>>>>>>>>> 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:
>>>>>>>>> On Mon, Sep 24, 2012 at 7:03 AM, Henri Colas <henri...@gmail.com<javascript:>
>>>>>>>>> > 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
>>>>>>>>>> Le dimanche 8 avril 2012 09:19:18 UTC+2, Stephen McDonald a >>>>>>>>>> écrit :
>>>>>>>>>>> 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.
>>>>>>>>>>> On Sun, Apr 8, 2012 at 4:55 PM, plaban nayak <
>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>> I made the home directory and all of its subdirectory >>>>>>>>>>>> writeable by everyone but still i am getting the same error.
>>>>>>>>>>>> Plaban
>>>>>>>>>>>> On Sun, Apr 8, 2012 at 12:12 PM, plaban nayak <
>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>> Ok got it .
>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:53 AM, plaban nayak <
>>>>>>>>>>>>> plaban...@gmail.com> wrote:
>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>> What should I do on my system?
>>>>>>>>>>>>>> Plaban
>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 11:44 AM, Stephen McDonald <
>>>>>>>>>>>>>> st...@jupo.org> wrote:
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>> On Sun, Apr 8, 2012 at 3:59 PM, plaban nayak <
>>>>>>>>>>>>>>> plaban...@gmail.com> wrote:
