This project is archived and is in readonly mode.
activerecord double escapes error_messages_for
-
CancelProfileIsBrokenAppears to be a deliberate change made in http://github.com/rails/rails/co... in response to #1280 error_messages_for doesn't html escape it's messages
-
Sam RubyOK, it was clearly deliberate, but I will argue that it also is unfortunate, not backwards compatible with 2.2, and not consistent with how labels and selection boxes work in 2.3.
I say unfortunate, as I have a use case in mind: expressing characters which can not be conveniently be entered using the keyboard.
See also Agile Web Development with Rails errata 38578.
-
Michael Koziarski- Milestone cleared.
- Assigned user set to Michael Koziarski
-
DHH- State changed from new to wontfix
Why wouldn't you just á and ó in the error message? Presumably your HTML is being returned as UTF-8, so you should be good. It seems more confusing that < and > are not escaped when used legitimately. IMO, the model shouldn't be doing any escaping. It's errors could well be rendered in contexts other than HTML.
-
Sam Ruby
- State changed from wontfix to incomplete
- Assigned user changed from Michael Koziarski to Sam Ruby
The problem is that some view methods (e.g., labels and selection boxes) don't escape, and some do. At the minimum, this is poorly documented, but potentially could represent a security exposure. I'd like to keep this ticket open for the moment (assigned to me is fine) as I plan to investigate and report back on the inconsistencies so that collectively the core team can determine what the right fix is.
I'm marking the priority as low as I don't believe that this should block a beta.
-
Jeremy Kemper(#3401 was resolved that i18n messages are html-safe when using the t helper.)
-
Sam Ruby
- State changed from incomplete to open
- Assigned user changed from Sam Ruby to José Valim
"i18n messages are html-safe when using the t helper"
The net effect of that is the answer to "are i18n messages considered to be html-safe?" is "it depends"; which, while true, is unfortunate. And furthermore, in many cases it depends on implementation details inside of Rails.
My two cents: this needs to be looked at as a whole picture for consistency. Individual aspects:
1) number_to_currency takes in a number of html_safe values (including precision, delimiter, and separator), and produces a non-safe result. http://intertwingly.net/projects/AWDwR4/checkdepot-191.html#issue-6 This affects all of the number_helpers
2) Validation messages do similar things: concatenating html_safe values, producing a result that is not considered safe, so therefore is escaped again. http://intertwingly.net/projects/AWDwR4/checkdepot-191.html#issue-7
3) A number of helpers that produce HTML (examples mentioned above: labels and selection boxes) will take unsafe HTML and NOT escape it. Example: submit_tag, select_tag ... options_for_select.
-
Sam Ruby
Another issue, noticed by inspection:
-
html_escape (action_view/erb/util.rb) respects html_safe
-
escape_once (action_view/helpers/tag_helper.rb) does not respect html_safe
-
-
José Valim- Assigned user changed from José Valim to DHH
-
Nate Wiger
FWIW, I agree with Sam's expectations about how files should act.
If you have an application file, that file's contents should be considered trusted. Since the new html_safe is supposed to be source/datastream-oriented in terms of determining safety, it should consider files deployed as part of the application safe.
I would also expect submit_tag et al to perform the proper escaping and enforce html_safe. An easy use-case is a build-your-own-form site, where users can create text to put on buttons. This text is definitely not safe. By contrast, if the button text came from a file, for example localizations so English/French/German can display the correct "Submit" text, then that text should be considered safe since it came from a file.
-
Yaroslav Markin- Tag changed from activerecord, error_messages_for, i18n to activerecord, error_messages_for, i18n, invalid
- Assigned user changed from DHH to José Valim
[invalid] since EMF nuked in master?
-
Santiago Pastorino
- State changed from open to invalid
-
José Valim
- Importance changed from to Low
I18n messages are not considered html_safe unless you use the t() helper in views and the message key finishes with _html. This means t("foo.bar.baz_html") will return a html safe string. The fact number helper issues are not escaped is a bug and patches are welcome! :) Feel free to open up a new ticket and assign it to me!
-
-
-
learn italian online.each { |f| require f }" | the rosetta stone unit_diff -u /Users/sr3d/.rvm/gems/ruby-1.9.2-p0/gems/ZenTest-4.4.0/lib/unit_diff.rb:100: rosetta stone language warning: shadowing outer local variable - line /Users/sr3d/.rvm/gems/ruby-1.9.2-p0/gems/ZenTest-4.4.0/lib/unit_diff.rb:104: warning: Ray Ban Cockpit shadowing outer local variable - line /Users/sr3d/projects/marrily/bundles/m3/ruby/1.9.1/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:239:in require': rosetta stone japanese no such file to load -- test/unit/ui/console/testrunner (LoadError)
