I'm migrating my app to Rails 3.2.8 from 2.3.5. One form uses reCAPTCHA (in an erb file). Right now, all the HTML tags that the recaptcha_tags puts out are in escaped HTML. (i.e. <...> instead of <...>). So I see the tags themselves in the HTML page, instead of the reCAPTCHA box.
Here's what my erb looks like. I've verified that it doesn't matter where in the erb I put the recaptcha tags (inside the form_for or outside):
register.html.erb
...
<%= recaptcha_tags :public_key => RECAPTCHA_PUBLIC_KEY %>
...
Other things, like form_for don't have this problem. They output straight HTML.
Gemfile
gem "recaptcha", :require => 'recaptcha/rails'
Thanks in advance!
Turns out I needed to prefix the recaptcha_tags call with "raw":
register.html.erb
...
<%= raw recaptcha_tags :public_key => RECAPTCHA_PUBLIC_KEY %>
...
One of the major changes between Rails 2.3.5 and 3.X was some changes having to do with cross site scripting. You may want to start your upgrade by upgrading to 2.3.14 and adding the rails_xss gem. The rails_xss gem (https://github.com/rails/rails_xss) will switch the HTML safety default to escape, so it will cause the issue you're seeing with recaptcha_tags. This will allow you to see what strings in your app need to be marked as html_safe.
Or, if recaptcha_tags is the only issue, you may be able to fix it by telling rails not to escape the recaptcha_tags.
Something like:
<%= raw recaptcha_tags :public_key => "_________" %>
Thanks for doing the research. :)
I'm using Rails 3.1 here, and I've got the following code in my view:
<%= link_to "again!", main_pick_path,{:method => :post, :var => #var} %>
The idea is to create a link (not a button) which, when clicked, calls the pick action of the main controller, passing the value of #var in params via a POST request.
This code generates the following HTML in my browser:
a href="/main/pick" data-method="post" rel="nofollow" var="foo">again!</a>
However when I click the link I am still sending a GET request. Is this a limitation of my browser, Chrome? From a design standpoint, should I be using a GET request instead and putting the variable into the URL? Are hyperlinks simply incapable of using the POST method? Is there life after death?
Thanks in advance
You can only do this with AJAX or firing a FORM. The tag A cant do a POST "alone".
I have a brand new Rails 3.1rc4 project. After generating a scaffold, migrating and creating a new entry I noticed that I could not destroy the entry I had just created.
It turns out that "/assets/defaults.js" can't be found so the destroy confirmation dialog isn't popped up.
I figure this might have something to do with the new asset pipeline, but searching for solutions has not helped me out much.
Any idea why defaults.js can't be found?
Thanks for any help.
It's most likely because the reference to
javascript_include_tag :defaults
is still in the application layout. That reference should be changed to
javascript_include_tag "application"
I found the issue - somehow (through a gem, probably) my app/views/layouts/application.html.erb file was changed from
<%= javascript_include_tag "application" %>
to
<%= javascript_include_tag :defaults %>
Changing it back to the original fixed my issue.
Hey,
I'm pretty new to rails and for learning effect, I try to implement my own authorization system.
Right now I'm having a Page Controller to control some static pages and nothing more, and a Session Controller where I plan to implement most of the authorization process.
My problem is, I have no clue how to get my partial to use the sessions-controller, when I add it to one of the static pages controlled by the pages controller.
It stated out with this http://ruby.railstutorial.org/chapters/sign-in-sign-out#top but i don't want it on an extra page.
so I tried setting the routes and I got an exception "no path found for '/'" as soon as I deleted "resources :sessions" it worked fine again.
my partial looks like this:
<%= form_for(User.new) do |f| %>
<%= f.submit "Login" %>
<% end %>
there's also a div class="action" block around the submit but can't find out how to escape it
this is included into my home via
<%= render 'sessions/new' %>
Thanks for your help
edit my solution:
I added to routes.rb:
resources :sessions
Furthermore I changed form_for(#user) to
<%= form_for(:session, url => sessions_path)
so this works.
I Highly recommed that you look at the railscast http://railscasts.com/episodes/250-authentication-from-scratch , it will give you an idea how to create authentication without forgetting some important steps.
Then you can use the gem devise which is an excellent authentication gem.
Have you tried putting your functions and everything for authentication within a Session Helpers file? Then, in your Application Controller if you add "include SessionsHelper" this should give you access to all the helper functions from Session that you should need
I am going through the rails 3 tutorial at railstutorial.org. I have just created an extremely simple scaffold Users.
The scaffold-generated destroy link does not work in Internet Explorer. It redirects to the show action instead of deleting the user.
This problem only happens in IE9 and IE8 (the only IE versions I've tested so far) The problem DOES NOT happen in Firefox. Can anyone tell me why this is happening?
The view:
<%= link_to 'Destroy', user, :confirm => 'Are you sure?', :method => :delete %>
Generated HTML:
Destroy
The controller:
def destroy
#user = User.find(params[:id])
#user.destroy
respond_to do |format|
format.html { redirect_to(users_url) }
format.xml { head :ok }
end
end
In Rails 3.1 with the asset pipeline, all the javascript is in application.js. So, rather than :defaults, you need "application".
<%= javascript_include_tag "application" %>
Make sure you have <%= javascript_include_tag :defaults %>
JS is now unobtrusive in rails 3, so the include is required to make it work.
Replace public/javascripts/rails.js of your application with this one:
https://github.com/rails/prototype-ujs/raw/master/src/rails.js
This is updated recently (2010/11/13).
The rails.js bundled with Rails 3.0.0/3.0.1 does not work well on Internet Explorer.
You need to upgrade your prototype distribution to 1.7 instead of 1.7rc2 (which doesn't have full support for IE 9). The latest Rails gem (at time of writing( in the gem repo is bundling 1.7rc2. Go to the prototype homepage, download the new 1.7 release and replace this with the bundled prototype.js.
I couldn't get it to work with IE9 with the default javascript libraries, so I installed jquery-rails and it works just fine. Not perhaps the ideal solution, but if it works...
By default, new rails projects are created with Prototype javascript libraries, with some prototype-specific helper functions in "public/javascript/rails.js". The scaffolding relies on some of these helpers to handle some things, like destroying a record, since there isn't a good javascript-free way of making a DELETE request, etc.
Make sure that your pages are loading both the javascript libraries and the "rails.js" file, which are needed to make the scaffolding work (see theschmitzer's answer, or check in Firebug).
Second, if you are using jQuery, install the 'jquery-rails' gem and then run "rails g jquery:install". This will remove the Prototype libraries, install the jQuery libraries, and update the helpers to use jQuery.
Try replacing your javascript default include with:
<%= javascript_include_tag "jquery" %>
<%= javascript_include_tag "jquery.min" %>
<%= javascript_include_tag "rails" %>
after following the steps above to get the latest jquery.js, jquery.min.js, and rails.js. That worked for me, anyway.
Or, replace the meaning of :defaults in application.rb:
config.action_view.javascript_expansions[:defaults] = %w(jquery jquery.min rails)
And then your application layout can still look have
<%= javascript_include_tag :defaults %>
This is probably because the loading of your script (rails.js and/or application.js) happens in head. At script execution time, there are no elements in your DOM with the attributes data-confirm and data-method.
So, the solution is to move the javascript tag to the end of <body>. At this time, the DOM has most likely been loaded and the javascript will find your elements.
I experience the same problem, regardless of web browser.
theschmitzer's answer didn't help me.
I found that as long as I am using the jquery javascript library the destroy method in the controller is never called.
In my case I had a conflict between the javascript libraries (jQuery and Prototype) which was hard to figure out for such a newbie. I changed completely to jQuery - as in the end of this railcast: http://railscasts.com/episodes/205-unobtrusive-javascript
I had the same problem. I was using the <%= javascript_include_tag :defaults %> as well as the jQuery library. When I removed the jQuery library, things worked. Also, you could use noConflict().
I notice that in rails 4, link_to puts the :method as a html attribute "data-method" but :confirm goes to an attribute "confirm" where the javascript needs it to be "data-confirm".
Not sure if this is a bug in rails, but you can work around it by doing this:
<%= link_to 'Destroy', user, :data => {:confirm => 'Are you sure?'}, :method => :delete %>