Thursday, February 12, 2015

How To Use GPG to Encrypt and Sign Messages on an Ubuntu 12.04 VPS

How To Use GPG to Encrypt and Sign Messages on an Ubuntu 12.04 VPS


Introduction

GPG, or GNU Privacy Guard, is a public key cryptography implementation. This allows for the secure transmission of information between parties and can be used to verify that the origin of a message is genuine.
In this guide, we will discuss how GPG works and how to implement it. We will be using an Ubuntu 12.04 VPS for this demonstration, but the tools are available on any modern Linux distribution.

How Public Key Encryption Works

A problem that many users face is how to communicate securely and validate the identity of the party they are talking to. Many schemes that attempt to answer this question require, at least at some point, the transfer of a password or other identifying credentials, over an insecure medium.

Ensure That Only the Intended Party Can Read

To get around this issue, GPG relies on a security concept known as public key encryption. The idea is that you can split the encrypting and decrypting stages of the transmission into two separate pieces. That way, you can freely distribute the encrypting portion, as long as you secure the decrypting portion.
This would allow for a one-way message transfer that can be created and encrypted by anyone, but only be decrypted by the designated user (the one with the private decrypting key). If both of the parties create public/private key pairs and give each other their public encrypting keys, they can both encrypt messages to each other.
So in this scenario, each party has their own private key and the other user's public key.

Validate the Identity of the Sender

Another benefit of this system is that the sender of a message can "sign" the message with their private key. The public key that the receiver has can be used to verify that the signature is actually being sent by the indicated user.
This can prevent a third-party from "spoofing" the identity of someone. It also helps to ensure that the message was transmitted in-full, without damage or file corruption.

Set Up GPG Keys

GPG should be installed by default on Ubuntu 12.04. If it is not, you can install it with:
sudo apt-get install gnupg
To begin using GPG to encrypt your communications, you need to create a key pair. You can do this by issuing the following command:
gpg --gen-key
This will take you through a few questions that will configure your keys.
  • Please select what kind of key you want: (1) RSA and RSA (default)
  • What keysize do you want? 4096
  • Key is valid for? 0
  • Is this correct? y
  • Real name: your real name here
  • Email address: your_email@address.com
  • Comment: Optional comment that will be visible in your signature
  • Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
  • Enter passphrase: Enter a secure passphrase here (upper & lower case, digits, symbols)
At this point, it will need to generate the keys using entropy. This is basically a term to describe the amount of unpredictability that exists in a system. GPG uses this entropy to generate a random set of keys.
It is best to open a new terminal and ssh into the VPS while this runs. Install some software, do some work, and just use the machine as much as possible to let it generate the needed entropy.
This process may take a long time, depending on how active you can make your system. There is an article here about how to generate additional entropy with haveged, which may be of use.

Create a Revocation Certificate

You need to have a way of invalidating your key pair in case there is a security breach, or in case you lose your secret key. There is an easy way of doing this with the GPG software.
This should be done as soon as you make the key pair, not when you need it. This revocation key must be generated ahead of time and kept in a secure, separate location in case your computer is compromised or inoperable. Type:
gpg --gen-revoke your_email@address.com
You will be asked for the reason that it is being revoked. You can choose any of the available options, but since this is being done ahead of time, you won't have the specifics.
You will then be offered to supply a comment and finally, to confirm the selections.
Afterwards, a revocation certificate will be generated to the screen. Copy and paste this to a secure location, or print it for later use:
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: A revocation certificate should follow

iQIfBCABAgAJBQJSTxNSAh0AAAoJEIKHahUxGx+E15EP/1BL2pCTqSG9IYbz4CMN
bCW9HgeNpb24BK9u6fAuyH8aieLVD7It80LnSg/+PgG9t4KlzUky5sOoo54Qc3rD
H+JClu4oaRpq25vWd7+Vb2oOwwd/27Y1KRt6TODwK61z20XkGPU2NJ/ATPn9yIR9
4B10QxqqQSpQeB7rr2+Ahsyl5jefswwXmduDziZlZqf+g4lv8lZlJ8C3+GKv06fB
FJwE6XO4Y69LNAeL+tzSE9y5lARKVMfqor/wS7lNBdFzo3BE0w68HN6iD+nDbo8r
xCdQ9E2ui9os/5yf9Y3Uzky1GTLmBhTqPnl8AOyHHLTqqOT47arpwRXXDeNd4B7C
DiE0p1yevG6uZGfhVAkisNfi4VrprTx73NGwyahCc3gO/5e2GnKokCde/NhOknci
Wl4oSL/7a3Wx8h/XKeNvkiurInuZugFnZVKbW5kvIbHDWJOanEQnLJp3Q2tvebrr
BBHyiVeQiEwOpFRvBuZW3znifoGrIc7KMmuEUPvA243xFcRTO3G1D1X9B3TTSlc/
o8jOlv6y2pcdBfp4aUkFtunE4GfXmIfCF5Vn3TkCyBV/Y2aW/fpA3Y+nUy5hPhSt
tprTYmxyjzSvaIw5tjsgylMZ48+qp/Awe34UWL9AWk3DvmydAerAxLdiK/80KJp0
88qdrRRgEuw3qfBJbNZ7oM/o
=isbs
-----END PGP PUBLIC KEY BLOCK-----

How To Import Other Users' Public Keys

GPG would be pretty useless if you could not accept other public keys from people you wished to communicate with.
You can import someone's public key in a variety of ways. If you've obtained a public key from someone in a text file, GPG can import it with the following command:
gpg --import name_of_pub_key_file
There is also the possibility that the person you are wishing to communicate with has uploaded their key to a public key server. These key servers are used to house people's public keys from all over the world.
A popular key server that syncs its information with a variety of other servers is the MIT public key server. You can search for people by their name or email address by going here in your web browser:
http://pgp.mit.edu/
You can also search the key server from within GPG by typing the following:
gpg --keyserver pgp.mit.edu  --search-keys search_parameters

How To Verify and Sign Keys

While you can freely distribute your generated public key file and people can use this to contact you in an encrypted way, there is still an issue of trust in the initial public key transmission.

Verify the Other Person's Identity

How do you know that the person giving you the public key is who they say they are? In some cases, this may be simple. You may be sitting right next to the person with your laptops both open and exchanging keys. This should be a pretty secure way of identifying that you are receiving the correct, legitimate key.
But there are many other circumstances where such personal contact is not possible. You may not know the other party personally, or you may be separated by physical distance. If you never want to communicate over insecure channels, verification of the public key could be problematic.
Luckily, instead of verifying the entire public keys of both parties, you can simply compare the "fingerprint" derived from these keys. This will give you a reasonable assurance that you both are using the same public key information.
You can get the fingerprint of a public key by typing:
gpg --fingerprint your_email@address.com
pub   4096R/311B1F84 2013-10-04
      Key fingerprint = CB9E C70F 2421 AF06 7D72  F980 8287 6A15 311B 1F84
uid                  Test User 
sub   4096R/8822A56A 2013-10-04
This will produce a much more manageable string of numbers to compare. You can compare this string with the person themselves, or someone else who has access to that person.

Sign Their Key

Signing a key tells your software that you trust the key that you have been provided with and that you have verified that it is associated with the person in question.
To sign a key that you've imported, simply type:
gpg --sign-key email@example.com
After you've signed the key, it means you verify that you trust the person is who he/she claims to be. This can help other people decide whether to trust that person too. If someone trusts you, and they see that you've signed this person's key, they may be more likely to trust their identity too.
You should allow the person whose key you are signing the advantages of your trusted relationship by sending them back the signed key. You can do this by typing:
gpg --export --armor email@example.com
You'll have to type in your passphrase again. Afterwards, their public key, signed by you, will be spit out on the screen. Send them this, so that they can benefit from gaining your "stamp of approval" when interacting with others.
When they receive this new, signed key, they can import it, adding on the signing information you've generated, into their GPG database. They can do this by typing:
gpg --import file_name

How To Make Your Public Key Highly Available

There is not really anything malicious that can happen if unknown people have your public key.
Because of this, it may be beneficial to make your public key easily available. People can then easily find your information to send you secure messages, from the very first communication.
You can send anyone your public key by requesting it from the GPG system:
gpg --armor --export your_email@address.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)

mQINBFJPCuABEACiog/sInjg0O2SqgmG1T8n9FroSTdN74uGsRMHHAOuAmGLsTse
9oxeLQpN+r75Ko39RVE88dRcW710fPY0+fjSXBKhpN+raRMUKJp4AX9BJd00YA/4
EpD+8cDK4DuLlLdn1x0q41VUsznXrnMpQedRmAL9f9bL6pbLTJhaKeorTokTvdn6
5VT3pb2o+jr6NETaUxd99ZG/osPar9tNThVLIIzG1nDabcTFbMB+w7wOJuhXyTLQ
JBU9xmavTM71PfV6Pkh4j1pfWImXc1D8dS+jcvKeXInBfm2XZsfOCesk12YnK3Nc
u1Xe1lxzSt7Cegum4S/YuxmYoh462oGZ7FA4Cr2lvAPVpO9zmgQ8JITXiqYg2wB3
. . .
You can then copy and paste this or send this in an appropriate medium.
If you want to publish your key to a key server, you can do it manually through the forms available on most of the server sites.
Another option is to do this through the GPG interface.
Look up your key ID by typing:
gpg --list-keys your_email@address.com
The highlighted portion is your key ID. It is a short way to reference the key to the internal software.
pub   4096R/311B1F84 2013-10-04
uid                  Test User 
sub   4096R/8822A56A 2013-10-04
To upload your key to a certain key server, you can then use this syntax:
gpg --send-keys --keyserver pgp.mit.edu key_id

Encrypt and Decrypt Messages with GPG

You can easily encrypt and decrypt messages after you have configured your keys with the other party.

Encrypt Messages

You can encrypt messages using the "--encrypt" flag for GPG. The basic syntax would be:
gpg --encrypt --sign --armor -r person@email.com name_of_file
The parameters basically encrypt the email, sign it with your private key to guarantee that it is coming from you, and generates the message in a text format instead of raw bytes.
You should also include a second "-r" recipient with your own email address if you want to be able to read the message ever. This is because the message will be encrypted with each person's public key, and will only be able to be decrypted with the associated private key.
So if it was only encrypted with the other party's public key, you would not be able to view the message again, unless you somehow obtained their private key. Adding yourself as a second recipient encrypts the message two separate times, one for each recipient.

Decrypt Messages

When you receive a message, simply call GPG on the message file:
gpg file_name
The software will prompt you as necessary.
If you have the message as a raw text stream, you can copy and paste it after you just typing gpg without any arguments. You can press "CTRL-D" to signify the end of the message and GPG will decrypt it for you.

Key Maintenance

There are a number of procedures that you may need to use on a regular basis to manage your key database.
To list your available GPG keys that you have from other people, you can issue this command:
gpg --list-keys
Your key information can become outdated if you are relying on information pulled from public key servers. You do not want to be relying on revoked keys, because that would mean you are trusting potentially compromised keys.
You can update the key information by issuing:
gpg --refresh-keys
This will fetch new information from the key servers.
You can pull information from a specific key server by using:
gpg --keyserver key_server --refresh-keys

Conclusion

Using GPG correctly can help you secure your communications with different people. This is extremely helpful, especially when dealing with sensitive information, but also when dealing with regular, every day messaging.
Because of the way that certain encrypted communications can be flagged by monitoring programs, it is recommended to use encryption for everything, not just "secret" data. That will make it more difficult for people to know when you are sending important data or just sending a friendly hello.
GPG encryption is only useful when both parties use good security practices and are vigilant about their other security practices. Educate those who you communicate regularly with about the importance of these practices if you want to have the possibility of cryptographically secure communication.

Wednesday, February 11, 2015

Django file browser doesn't work django-filebrowser

django-filebrowser and grapelli
django-grappelli provides a revamp of the existing django admin look-and-feel. In itself, it simply makes your site look better – you’ll need this in case a site also needs to provide admin access to the product owner. For this case, however, we’re using grappelli as a dependency for django-filebrowser.
django-filebrowser does exactly what its name says. In a nutshell, django-filebrowser lets you navigate through and manipulate your media files through your django admin site. This is useful should you eventually need the end-user to be able to control image files without having to dig deep into the server’s internal filesystem.
First, make sure the dependencies are installed. PIL may prove tricky to install, but from there it’s all simple.
  • pip install django==1.2
  • pip install PIL==1.1.7
  • pip install django-grappelli=2.1
  • pip install django-filebrowser==3.1
You’ll be able to follow these steps, except for the ‘collectstatic’ management command (since we’re using Django 1.2) http://django-grappelli.readthedocs.org/en/latest/quickstart.htmlAlso, I used these additional settings:
Note: the PROJECT_ROOT style makes your settings more portable, so it’s a good habit to start.
Next, we make a symbolic link to the grappelli media folder (in site-packages) from your project media folder.(In the directory defined by MEDIA_ROOT)ln —symbolic /PATH/TO/site_packages/grappelli/media grappelli
Then, make sure your installed apps has this order:
Same goes for your urls,
(In the directory defined by MEDIA_ROOT)
Indicate in additional settings using this as reference:http://code.google.com/p/django-filebrowser/wiki/Settings
Once you’re set up, check it out with the following url:/admin/filebrowser/browse/

I have installed Django file browser and added grappelli and filebrowser to my installed apps. And did every thing said in documention but when I browse http://127.0.0.1:8000/admin/filebrowser/ I got 404 page not found error. What's the problem? I configured my media settings like this:
# Media files
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'
ADMIN_MEDIA_PREFIX = '/media/admin/'
FILEBROWSER_DIRECTORY = '/media/'

2 answers

  • answered 2014-02-11 17:59 frnhr
    Just solved the exact same problem, and it's the oldest one in the book: permissions (facepalm)
    • make sure your media dir is chmod-ed to 755
    • create media/uploads dir and also chmod it to 755
    In settings.py, I don't use the FILEBROWSER_DIRECTORY (I guess that uploads is the default)
    I really think that throwing 400 Bad Request is utterly useless and anoying, but oh well...

    Just a related note: I don't think there is anything at /admin/filebrowser/, it just gives me a 404. Please correct me it I'm missing something here :)

  • answered 2014-02-11 17:59 pryma
    The problem is your FILEBROWSER_DIRECTORY setting. It should have absolute path.
    Unfortunately, the error is hidden by the nasty 400 Bad Request, as explained in this ticket.
Django] #21668: Invalid upload_to attribute results in hard-to-debug "Bad Request" 400 error.
12 posts by 1 author
Django
12/25/13
#21668: Invalid upload_to attribute results in hard-to-debug "Bad Request" 400 error. -------------------------------+--------------------      Reporter:  GDorn          |      Owner:  nobody          Type:  Bug            |     Status:  new     Component:  Uncategorized  |    Version:  1.6      Severity:  Normal         |   Keywords:  Triage Stage:  Unreviewed     |  Has patch:  0 Easy pickings:  0              |      UI/UX:  0 -------------------------------+--------------------  It's admirable that django tries to prevent files from being uploaded  outside of MEDIA_ROOT.  However, the documentation for file uploads  (https://docs.djangoproject.com/en/dev/topics/http/file-uploads/) doesn't  make this requirement clear, and getting it wrong results in several  layers of useful error messages getting eaten by a generic message  instead. It starts with django.utils._os.safe_join raising a ValueError if the  upload_to path isn't within MEDIA_ROOT.  This has a useful message payload  showing both paths and why the exception happened.  This message isn't  logged.
 However, django.core.files.storage.FileSystemStorage.path immediately  catches that exception, eats the message, and raises a much more generic  SuspiciousFileOperation, containing the desired path but no explanation of  what went wrong.
 Finally, django.core.handlers.base.BaseHandler.get_response catches that  SuspiciousOperation, logs the message (good if you have logging turned on,  which many users do not), eats the exception and returns a 400 response  instead.
 All the user sees is "400 Bad Request", no traceback and certainly not the  original and useful ValueError message.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668> Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.



Django
12/25/13
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. (was: Invalid upload_to attribute results in hard-to-debug "Bad Request" 400 error.)
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. -------------------------------+--------------------------------------
     Reporter:  GDorn          |                    Owner:  nobody          Type:  Bug            |                   Status:  new     Component:  Uncategorized  |                  Version:  1.6
     Severity:  Normal         |               Resolution:      Keywords:                 |             Triage Stage:  Unreviewed     Has patch:  0              |      Needs documentation:  0   Needs tests:  0              |  Patch needs improvement:  0
Easy pickings:  0              |                    UI/UX:  0
-------------------------------+-------------------------------------- Changes (by GDorn): * needs_better_patch:   => 0  * needs_docs:   => 0  * needs_tests:   => 0
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:1>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.

Django
12/25/13
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. -------------------------------+--------------------------------------
     Reporter:  GDorn          |                    Owner:  nobody          Type:  Bug            |                   Status:  new     Component:  Uncategorized  |                  Version:  1.6
     Severity:  Normal         |               Resolution:      Keywords:                 |             Triage Stage:  Unreviewed
    Has patch:  0              |      Needs documentation:  0
  Needs tests:  0              |  Patch needs improvement:  0
Easy pickings:  0              |                    UI/UX:  0
-------------------------------+--------------------------------------Comment (by anonymous):
 Potentially related #19866
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:2>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.


Django
3/16/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. -------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:  nobody          Type:                       |                   Status:  new   Cleanup/optimization               |                  Version:  1.6     Component:  HTTP handling        |               Resolution:      Severity:  Normal               |             Triage Stage:      Keywords:                       |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+------------------------------------- Changes (by timo): * cc: timo (added)  * component:  Uncategorized => HTTP handling  * type:  Bug => Cleanup/optimization
Comment:
 There may be some room for improvement here. How/why did you manage to  attempt to upload a file outside of `MEDIA_ROOT`?
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:3>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.



Django
3/18/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. -------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:  nobody
         Type:                       |                   Status:  new   Cleanup/optimization               |                  Version:  1.6     Component:  HTTP handling        |               Resolution:      Severity:  Normal               |             Triage Stage:      Keywords:                       |  Unreviewed     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------Comment (by GDorn):
 I was attempting to simulate the upload as part of a unit test.  As I  didn't want the test polluting my actual uploads directory, I was  attempting to use @override_settings to change the upload path.  The  resulting error was very hard to diagnose.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:4>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.


Django
3/28/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. --------------------------------------+------------------------------------      Reporter:  GDorn                 |                    Owner:  nobody          Type:  Cleanup/optimization  |                   Status:  new     Component:  Documentation         |                  Version:  1.6      Severity:  Normal                |               Resolution:      Keywords:                        |             Triage Stage:  Accepted
    Has patch:  0                     |      Needs documentation:  0
  Needs tests:  0                     |  Patch needs improvement:  0
Easy pickings:  0                     |                    UI/UX:  0
--------------------------------------+------------------------------------ Changes (by timo): * component:  HTTP handling => Documentation  * stage:  Unreviewed => Accepted
Comment:
 I think improving the documentation is the best way forward.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:5>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.



Django
5/18/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error. -------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:          Type:                       |  anubhav9042   Cleanup/optimization               |                   Status:  assigned
    Component:  Documentation        |                  Version:  1.6      Severity:  Normal               |               Resolution:      Keywords:                       |             Triage Stage:  Accepted     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+------------------------------------- Changes (by anubhav9042): * status:  new => assigned  * owner:  nobody => anubhav9042
Comment:
 Working on this in my GSoC project.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:6>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.



Django
5/26/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
-------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:          Type:                       |  anubhav9042   Cleanup/optimization               |                   Status:  assigned     Component:  Documentation        |                  Version:  1.6      Severity:  Normal               |               Resolution:      Keywords:                       |             Triage Stage:  Accepted     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------Comment (by timo):
 Actually, it appears that this raised a more informative error message in  Django 1.3 (see #22706). We should see if that's possible to restore.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:7>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.


Django
6/17/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
-------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:          Type:                       |  anubhav9042   Cleanup/optimization               |                   Status:  assigned
    Component:  Documentation        |                  Version:  master
     Severity:  Normal               |               Resolution:      Keywords:                       |             Triage Stage:  Accepted     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+------------------------------------- Changes (by anubhav9042): * version:  1.6 => master
Comment:
 Since this appears to be a problem in not getting the correct message, I  am going to fix this alongwith #22058.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:8>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.



Django
6/23/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
-------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:          Type:                       |  anubhav9042   Cleanup/optimization               |                   Status:  assigned     Component:  Documentation        |                  Version:  master      Severity:  Normal               |               Resolution:      Keywords:                       |             Triage Stage:  Accepted     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------Comment (by timo):
 This regressed in 1.6 with this commit:  https://github.com/django/django/commit/d228c1192ed59ab0114d9eba82ac99df611652d2  #diff-dbd7d9159676b15fc9a096b0adb919e9R173
 I think we should consider returning a `technical_500_response` in the  handling of `SuspiciousOperation` as we did before if `settings.DEBUG is  True` rather than invoking `handler400`.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:9>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.



Django
6/24/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
-------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:          Type:                       |  anubhav9042   Cleanup/optimization               |                   Status:  assigned     Component:  Documentation        |                  Version:  master      Severity:  Normal               |               Resolution:      Keywords:                       |             Triage Stage:  Accepted     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------Comment (by timo):
 Yes, that's the idea. Please add a test. A mention in the release notes  also wouldn't hurt. I'd also consider adding a `status_code` kwarg to  `technical_500_response` so we can continue returning a `400` in this  case.
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:10>
Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines.


Django
6/24/14
Re: [Django] #21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
#21668: Invalid upload_to FileField attribute results in hard-to-debug "Bad Request" 400 error.
-------------------------------------+-------------------------------------      Reporter:  GDorn                |                    Owner:          Type:                       |  anubhav9042
  Cleanup/optimization               |                   Status:  closed     Component:  Documentation        |                  Version:  master      Severity:  Normal               |               Resolution:  fixed
     Keywords:                       |             Triage Stage:  Accepted     Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+------------------------------------- Changes (by Tim Graham ): * status:  assigned => closed  * resolution:   => fixed
Comment:
 In [changeset:"dbbcfca476e29354c3a5c6221112b55741babc14"]:  {{{  #!CommitTicketReference repository=""  revision="dbbcfca476e29354c3a5c6221112b55741babc14"  Fixed #21668 -- Return detailed error page when SuspiciousOperation is  raised and DEBUG=True
 Thanks GDorn and gox21 for report.
 Thanks Tim Graham for idea and review.  }}}
-- Ticket URL: <https://code.djangoproject.com/ticket/21668#comment:11>