Opened 13 years ago

Last modified 11 years ago

#14976 closed

Add is_safe flag to contrib.messages — at Initial Version

Reported by: Ted Owned by: nobody
Component: contrib.messages Version: dev
Severity: Normal Keywords: safe, messages, html
Cc: florian+django@… Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I would like to have add a message.is_safe flag to the Message model of the contrib.messages app.

The flag would be set to False by default and could be explicitly overridden for trusted messages. There are times when it would be helpful to the end user to include an html link in a message ("Welcome, click here to create a profile", "You've sent 25 points to user_b, click here to see your balance," etc.), and with the current message system there is not a good way to do this.

Adding the is_safe flag would require a minor set of backward compatible changes:

def success(request, message, extra_tags='', fail_silently=False):
to
def success(request, message, extra_tags='', fail_silently=False, is_safe=False):

def add_message(request, level, message, extra_tags='', fail_silently=False):
to 
def add_message(request, level, message, extra_tags='', fail_silently=False, is_safe=False):

def __init__(self, level, message, extra_tags=None): 
to
def __init__(self, level, message, extra_tags=None, is_safe=False):

#add to __init__
self.is_safe = is_safe

Then in the template: {% if message.is_safe %} {{ message|safe }}{% else %}{{ message }}{% endif %}.


Alternative ways to do this:

  1. Run all messages through the safe filter

This would require a code-wide policy of "make sure you escape anything in a message that might have user input" such as if my message is "your post %s is now published" % blog.post or "%s has sent you the message %s" %(user, message.content). I would then have to worry about every variable I use in a message string, if it could contain script, and if it is already escaped (or escape everything again). I would also have to worry if everyone else working on the codebase is doing this correctly.

2.Use a tag
I could have a policy of adding "safe" to the tags I want to run through the safe filter, but this is also fraught with downsides. Since all tags get output into html, the safe flag would end up output to the end user. The template logic is less clear and error prone {{ "test" in message.extra_tags }} would work, but would return a false positive if you tried to use "contest" as a tag. Granted "contest" as a message tag is a rare case; it is just another layer of messiness of security code mashed in with markup.

If this isn't violating a core django design precept, I'll get started on a patch in the next few days.

Change History (0)

Note: See TracTickets for help on using tickets.
Back to Top