Commit Graph

11 Commits

Author SHA1 Message Date
Javi Martín
7bf4e4d611 Sanitize descriptions in the views
Sanitizing descriptions before saving a record has a few drawbacks:

1. It makes the application rely on data being safe in the database. If
somehow dangerous data enters the database, the application will be
vulnerable to XSS attacks
2. It makes the code complicated
3. It isn't backwards compatible; if we decide to disallow a certain
HTML tag in the future, we'd need to sanitize existing data.

On the other hand, sanitizing the data in the view means we don't need
to triple-check dangerous HTML has already been stripped when we see the
method `auto_link_already_sanitized_html`, since now every time we use
it we sanitize the text in the same line we call this method.

We could also sanitize the data twice, both when saving to the database
and when displaying values in the view. However, doing so wouldn't make
the application safer, since we sanitize text introduced through
textarea fields but we don't sanitize text introduced through input
fields.

Finally, we could also overwrite the `description` method so it
sanitizes the text. But we're already introducing Globalize which
overwrites that method, and overwriting it again is a bit too confusing
in my humble opinion. It can also lead to hard-to-debug behaviour.
2019-10-21 21:32:02 +02:00
Javi Martín
2aabf79fb4 Rename methods to add auto links to HTML
The name `safe_html_with_links` was confusing and could make you think
it takes care of making the HTML safe. So I've renamed it in a way that
makes it a bit more intuitive that it expects its input to be already
sanitized.

I've changed `text_with_links` as well so now the two method names
complement each other.
2019-10-08 18:46:20 +02:00
Javi Martín
6fa67b5e53 Use active record translations for labels
This way we can simplify the way we generate form fields. In some cases,
we also use the human attribute in table headers, which IMHO makes
sense.

I haven't moved all of them: for example, sometimes a label is
different depending on whether it's shown to administrators, valuators,
or users. And I haven't touched the ones related to devise, since I
wasn't sure about possible side effects.

Note I've also removed placeholders when they had the same text as their
labels, since they weren't helpful. On the contrary, the added redundant
text to the form, potentially distracting users.
2019-10-07 01:56:23 +02:00
Javi Martín
1bc66925ab Remove redundant labels
We already had translations for these attributes.
2019-10-07 01:55:56 +02:00
Javi Martín
aec84f6522 Generate labels for attribute automatically
I'm not sure why it isn't already done by foundation's form builder. It
doesn't make any sense to change an ID of a form field without changing
the `for` attribute of its label.
2019-10-06 19:32:04 +02:00
Javi Martín
3ea9f3cecf Simplify generating form fields with labels
Instead of generating the label and then a field without a label, we can
directly generate a field with a label.
2019-10-05 16:01:58 +02:00
taitus
12089282c8 Align admin progress bars form fields with new translations interface
Add new js method to recover selected language to disable correctly default language fields.
2019-07-01 15:03:48 +02:00
taitus
a700ea2fce Align admin milestones form fields with new translations interface 2019-07-01 14:49:44 +02:00
Senén Rodero Rodríguez
146c09adb7 Update references to new translation interface 2019-07-01 14:49:43 +02:00
German Galia
74083df10f Add historic fields to participatory budget 2019-06-12 18:03:53 +02:00
German Galia
9ce524e1f3 Create tracker rol 2019-06-12 16:23:40 +02:00