I'm doing maintenance on an old rails app, and my rails wasn't that great to begin with. I'm seeing the following code all over in forms in views; this example is from a payment/billing screen, so the fields are common billing fields like address fields:
<%= t : "front.City" %>
This is used for the form field label. I can't figure out what either the 't' is, or the 'front'. I'm trying to copy this partial for a different payment method. When I changed the 'front.new-label', it broke something because it then displayed the label as
en, front, new-label
I'm wondering if the 't' is some kind of helper method, like <%=h is to sanitize output. This is used in a partial, so I looked in the layout that includes the partial to see if 'front' was defined anywhere in there but didn't find anything. This 't' and 'front' are used all over the app as labels, so I thought it just had something to do with styling. But it's used so often that I can't see all these front.variables being defined somewhere, but then why does it break when I change it?
You're correct, t is a short-cut for the i18n translation method:
http://railsapi.com/doc/rails-v2.3.8/classes/ActionController/Translation.html#M001880
Have a read of the internationalisation guide to get a feel for what's going on.
Related
I am working on a Rails application whose HAML templates frequently make use of a routine called sanitize. I have deduced from context that this routine sanitizes user-controlled HTML. Example:
# views/feed_items/_about.html.haml
%h3 Summary:
.description
= sanitize #feed_item.description
I want to make this routine add 'rel=nofollow' to all outbound links, in addition to what it's already doing. What is the most straightforward way to do that?
N.B. I am not having any luck finding the definition of this method, or the official configuration knobs for it. The vendor directory has two different HTML sanitizer gems in it and I can't even figure out which one is being used. This is a large, complicated web application that I did not write, and I barely understand Ruby, let alone all of Rails' extensions to it. Please assume I do not know any of the things that you think are obvious.
The sanitizer will strip out the rel tags if they exist.
I ran into a similar issue and added an additional helper method - clean_links to the ApplicationHelper module, and called it after sanitizing the content.
# application_helper.rb
def clean_links html
html.gsub!(/\\2')
html.html_safe
end
This method looks for all <a> tags, and adds rel="nofollow". The html_safe method is necessary or else the HTML will be displayed as a string (it's already been sanitized).
This solution treats all links equally, so if you only want this for links pointing outside the domain, you'll have to update the REGEX accordingly.
In your view: <%= clean_links sanitize(#something) %>
So, first the content is sanitized, then you add the rel="nofollow" tag before displaying the link.
Actually there's a built-in way:
sanitize "your input", scrubber: Loofah::Scrubbers::NoFollow.new
Experimenting with my Rails form, I find that inserting <scrip>alert("hello")</script> into a text_field gives me two different results.
When I use the value, for example in a display page, it is automagicaly escaped.
When I use the value in a new form, for example to allow user editing, it is not escaped and I get the alert pop-up.
After a lot of research, I have found that text_area has an escape boolean that prevents this, but not text_field. Most of the stuff coming up on google is about escaping within erb templates, which does not appear to work when using a form. There are a couple of hints that data should be sanitized going into the db, but little guidance on the best way to do this --- aside from using old solutions for example xssterminate which appears to date back to Rails 2. Even the RoR security guide focuses on sanitizing erb output rather than santizing the input.
Two questions.
What is the current best-practice approach to sanitizing text_field input before it is saved? (eg: in the form, the controller or the model. What gems are still considered current?)
Regardless, because I am paranoid, how do you sanitize the text_field when displaying db data?
The loofah-activerecord gem (https://github.com/flavorjones/loofah-activerecord) looks like your best bet for sanitizing data on its way into the database. Using xss_foliate on your models will strip tags for all columns by default.
e.g.
class User < ActiveRecord::Base
xss_foliate
...
end
I haven't found a solution to the 2nd point, but would be very keen to know about it if there is one!
I think I already know the answer to this, but I'm going to ask it anyway.
I've got a rails app, and integrating angular into one of the areas of the app to get some of that magic. To add to the mix I'm integrating the Chewy gem to use ElasticSearch.
So, using this example:
I have a Presentation model with the following fields:
id
venue id
presentation id
rating
I have a Presentations view with loops through a Presentation partial and I'm doing essentially the same thing with Angular and I'm looping through a Presentation directive.
Now, with normal ERB when I pull a list of presentations in the ERB view I could just have: <%= presentation.venue.name %> to show the venue's name.
What I'm wondering is, and like I said I think I already know the answer to this, going the angular route through this when I'm looping through my Presentation directive, even though it's an _presentation.html.erb file I can't use the active record relation because javascript get's rendered after the html.
So, in my angular directive template, where instead I would have presentation.venue.name I would need to have an angular function that would pull that in, right?
Is there some way, when I'm pulling the data in through ElasticSearch/Chewy I could pull this data in as well? That's my only other option I believe?
Example, i made a form like this
<form name="register" method="post" enctype="multipart/form-data">
<p><h3>User check</h3></p>
<p>admin ID: <input type="text" name="userid"></p>
<p>admin Pass: <input type="password" name="password"></p>
<input type="submit" name="apply" value="Submit"></p>
<p> </p>
</form>
and my manager wants to change this form to rails form template like this,
<%= form_for(:model) do |form| %>
<p>
<%=form.label :input%>
<%=form.text_field :input, :placeholder => 'Enter text here...'%>
</p>
<%end%>
My question is, it works fine with html based front code. Why do i have to change this to rails code? I just want to keep my front-end code...I don't know why i have to change this :(. Also, I'm new on Ruby on Rails. That is the main reason. I dont' want to change the existing code, if it is working.
I really hate this job. I have to translate all the attributes to the rails code and that makes me really exhausted :(
Form builders are here to help
Form helpers are supposed to make your life simpler. They are quicker to write than their pure html alternative, provided you don't write pure html first.
They also provide a lot of easy implementations for difficult integration pieces, like :
displaying a date selection select group
mirroring the fact that a check box has been unchecked in POST params
automatically adding multipart param on form if you add a file input (not actually difficult to achieve, but easy to forget)
... and many more
Further development
All of this is about comfort, and you may think you could avoid it if you already have a perfectly working pure html implementation.
But what happen if someone later has to add a date select input in your form ? She will have to use the rails helper, since it saves a lot of time in controller part to set date in database. But she won't be able to leverage form builder, since you haven't used it.
Now, she has to choose between using a non builderdate_select tag mixed in pure html or ... to rewrite your form completely. As you may realize, mixing different styles is generally considered ugly, and we don't like ugly in ruby.
Security
Form tag helpers also provide an important security measure : CSRF protection. Every time you use a rails helper to create a <form> tag, it automatically adds an hidden input containing a secret key. That key has to be posted with form data to prove request originated from current website.
If you use plain html forms, you won't have this security. You could of course add the token manually using the correct method, but this would again be more time wasting than simply using form helpers.
Bottom line
The main problem is that you write pure html before using rails helpers - that is what is wasting time.
Some benefits of using Rails form helpers are:
Consistent naming of input elements names and ids
i18n support for labels
generated URL with form_for is less error prone
Better handling of checkboxes
Nice helpers like options_for_select
Less typing
That last ones might be my favourite: less typing.
I'm writing a rails app that allows users to delete records of various sorts. After pressing a delete button, I'd like to show a confirm dialog using bootstrap. I'd like to use this same dialog in several of my views, so I'll need to include the same HTML snippet in most of my pages.
I'm new to rails and I'm still learning the conventions. Can anyone suggest the best (or standard) place to put the dialog code? Should it be a partial in views/layouts/_confirm_delete_dialog.html.erb, should it go inside application.html.erb, or should I put it somewhere else?
Thanks in advance for your advice,
D.
Within your Views folder, you can create a general folder (called whatever you want). If you have a variable that you need to pass through to the general layout, you can definitely do so, but you will want to make sure that the information that you're passing through doesn't cause conflicts with the fields pulled from the model. For example, if you have two models and one has a public field but the other doesn't then you will not want to have a generic message that is using the public field. However, something like the created_at or updated_at would be okay.
You would use a code similar to,
<%= render 'general/simple_message', :f => f %>
In your views folder, you would have a directory called general and a file called _simple_message.html.erb.