In my Rails 4 application I have a model that needs to build links to other parts of the application. I am using Rails.application.routes.url_helpers.<path_name> to generate the URL of this link. The problem I have is that this generated path doesn't included the nested path.
Locally the app is served to localhost:3000 and all the paths work correctly, but when I deploy to a remote server it is served by Nginx/Passenger using the root http://<servername>/admin and the paths are incorrect. So as an example, what I want is payments_path to resolve to "/admin/payments", but instead I get "/payments".
The strange thing is when I use payments_path directly in my view or other places in my app, I get the path with the nested /admin path, ie "/admin/payments".
Anyone have any idea why path is giving me two different things in the view and the Rails.application.routes.url_helpers?
I think the core issue is that path generation at the view / controller level is getting some additional metadata to generate the paths correctly. I ended up finding a blog post dealing with the subject of routes inside models.
The author of the blog (Adam Hawkins) recommends the following approach for adding paths generation as a concern to the model,
module Routing
extend ActiveSupport::Concern
include Rails.application.routes.url_helpers
included do
def default_url_options
ActionMailer::Base.default_url_options
end
end
end
class UrlGenerator
include Routing
end
This concern piggybacks off the ActionMailer configuration, which in my case is,
config.action_mailer.default_url_options = { host: 'https://dev.<domain-name>.com/admin' }
However after I added this concern I still couldn't generate the full relative path, but I could get the absolute url generation working. So I ended up using payments_url instead of payments_path.
I think there is probably a way to get relative paths to work, but this is my workaround for the time being.
Related
I'm a beginner to both ruby and rails, and using Rails 5.17 to develop a web app for a class.
Creating the empty Rails project was successful, but something is going wrong when creating a new controller. I generated a new controller named cars from the root of the project, which was successful. There was a file in app/controllers named cars_controller.rb which looks like this:
class CarsController < ApplicationController
end
I added a method to this file named hello that does nothing.
I then created a file named cars.html.erb in the app/views/layouts directory. This file is a basic page of html code.
In config/routes.rb, I added the following:
get '/cars', to:: 'cars_controller#hello'
resources: cars
After all of this, I ran rails server, and opened localhost:3000 in a browser. This brings up the normal Ruby on Rails welcome page.
But when I go to localhost:3000/cars, I get the following:
Routing Error
uninitialized constant CarsControllerController
I've tried changing the name of the cars_controller.rb file. I've tried changing the name of the class in the controller file from CarsController to Cars. I've tried many different routes in routes.rb. I finally tried uninstalling Rails 5.17 and installing Rails 5.13.
I'm very confused, and I'd be grateful for any advice I can get. Thanks in advance!
One of the great things about Rails is its preference for convention over configuration. However, for this to really benefit you, you need to stick to doing things “The Rails Way” rather than your own way, wherever possible.
In this case, start by getting rid of your custom get route, and just use resources :cars.
From the command line, run rake routes (you might be able to run rails routes on your rails version too) and see the routes that it has created for you.
Now, rename the method you added to your CarsController from hello to index.
Move your hello.html.erb file from app/views/layout to app/views/cars/index.html.erb.
Finally, start the rails server (rails start) and load the url http://localhost:3000/cars in your browser.
—-
Note that templates in app/views/layout have a special purpose. These are used to apply a general template to your views. Look up the use of layout within a controller for more details
I think you have an error in how you had defined your route - you don't need _controller.
Instead, try this:
get '/cars', to: 'cars#hello'
Also, keep in mind that in your cars directory you need the view: hello.html.erb
I'm trying to create an "asset controller" shim which will filter static asset requests so only authorized users can get retrieve certain assets. I wanted to continue to use the asset pipeline so I setup a route like this
get 'assets/*assetfile' => 'assets#sendfile'
Then I created an AssetsController with one method "sendfile". Stripping it down to only the stuff that matters, it looks like this:
class AssetsController < ApplicationController
def sendfile
# Basically the following function forces the file
# path to be Rails.root/public/assets/basename
assetfilename=sanitize_filename(params[:assetfile] + '.' + params[:format])
send_file(assetfilename)
end
end
It looks like I have to run this in production mode as rails by-passes my route for assets in development. So I precompile my assets and I can verify in the controller that the files exist where they are expected to be.
However, now the problem is that I'm getting a "ActionController::InvalidCrossOriginRequest" when the Javascript asset is requested (just using the default application.* assets for now). I've read about this error and I understand that as of Rails 4.1 there are special cross-origin protections for Javascript assets. Sounds good to me, but I don't understand where the "cross-origin" part is coming from. Using firebug, I can see that the asset requests are being requested from the same domain as the original page.
I am certain that this is the problem because I can solve it by putting "skip_before_action :verify_authenticity_token" in the beginning of my controller. However, I really don't want to do this (I don't fully understand why this check is necessary, but I'm sure there are very good reasons).
The application.html.erb file is unchanged from the default generated file so I assume it's sending the CSRF token when the request is made, just as it would if I didn't have my own controller for assets.
So what am I missing?
Ok, I think I answered my own question (unsatisfactorily). Again, long post, so bear with me. I mistakenly forgot to add this to my original questions, but I'm using Ruby 2.2.0 and Rails 4.2.4.
From looking at the code in "actionpack-4.2.4/lib/action_controller/metal/request_forgery_protection.rb", it looks like Rails is doing two checks. The first check is the "verify_authenticity_token" method which does the expected validation of the authenticity token for POST requests. For GET requests, it ALSO sets a flag which causes a second check on the formed computed response to the request.
The check on the response simply says that if the request was NOT an XHR (AJAX) request AND the MIME Type of the response is "text/javascript", then raise an "ActionController::InvalidCrossOriginRequest", which was the error I was getting.
I verified this by setting the type to "application/javascript" for ".js" files in "send_file". Here's the code:
if request.format.js?
send_file(assetfilename, type: 'application/javascript')
else
send_file(assetfilename)
end
I can skip the response check all together by just adding the following line to the top of my controller class:
skip_after_action :verify_same_origin_request
The check on the response seems pretty weak to me and it's not clear how this really provides further protection against CSRF. But I'll post that in another question.
My /blog directory is just a bunch of static HTML files. That's good.
When I go to localhost/blog it works fine - it renders the index.html for my middleman generated blog. Great.
But when I click on any of the posts, it gives me a routing error:
No route matches [GET] "/blog/2015/03/11/hello_world"
I am pretty sure the reason this is happening is because of one of these rules in my routes.rb:
get '/:friendly_id', to: 'posts#show'
get '/rbt/:name', to: redirect {|path_params, _| "/#{path_params[:name].gsub(/^\d+\-/, '')}" }
get ':name', to: 'posts#show'
I need all of these routes, but I don't want an HTML request to hit my Rack middleware unnecessarily....or worse yet, do a DB query which this error seems to suggest is happening.
How do I confine all requests to /blog/ to just resolve to my public/blog/ directory?
Edit 1
I realize the above description may not be clear. My Rails App isn't a blog, and so the posts you see referenced above, are not posts to the blog. They are posts of another kind, separately managed by the Rails app with a DB and all. I have since added a real /blog which will just be a collection of HTML articles generated by MiddleMan that will sit in my Rails /public/blog folder. The idea being that the HTML files in my /blog directory, should not hit my Rack middleware at all.
You can force rack to serve certain folder as static and routes-ignoring by adding config.middleware.use Rack::Static, urls: ['/blog'], root: 'public' to config/application.rb but imho it's better to setup a web server to intercept and serve /blog earlier than your app does.
And also in your case /blog/2015/03/11/hello_world seems to be a directory name, if you add index.html to the link it should work as you expect, without changing any configuration.
When your app is run by webserver, its webroot will be the public directory. So, if you have your blog directory inside public directory this should work. localhost/blog
Try running with nginx with following config :
root /root/path/to/your_app/public;
Couldn't you create a static_url controller and configure your routes so that
get '/blog', to: 'static_url#show'
Then in your controller have
def show
render file: request.fullpath
end
Sorry I can't test right now but I'm sure you get the idea. Also, I guess you would need to detect non-existent pages.
When you create a namespaced model with rails scaffolding, you get two files. For example, this scaffold:
rails generate model Staff::Location name:string address:string
Generates these files:
/app/models/staff.rb
module Staff
def self.table_name_prefix
"staff_"
end
...
/app/models/staff/location.rb
class Staff::Location < ActiveRecord::Base
...
I am running into problems when in development mode where rails unloads the Staff module and never reloads it. This causes several annoying bugs such as Location not able to access it's table due to the missing table_name_prefix. The problem seems to crop up when I don't access the models directly, such as through a polymorphic relationship.
I can't seem to get the module loaded on a consistent basis. Is this the best practice way to do namespaced models? If it is, what am I missing?
Although I wasn't able to reproduce the problem in Rails 3.2.2, I've run into something like this before. The generic way to hack around this problem in development mode is through an ActionDispatch callback. Add this to config/environments/development.rb:
MyApp::Application.configure do
ActionDispatch::Callbacks.before do
load Rails.root.join('app', 'models', 'staff.rb')
end
end
Anything you do in that block will be executed before each request, so make sure you're only doing it in development mode.† Otherwise, you're going to suffer a performance hit in production.
I logged a message inside the staff.rb file and within the Staff module itself, and both messages appeared in the log for each request.
† I tried using the to_prepare callback, since that seems to be the documented way to execute code before each request only when cache_classes is false. But that only seemed to execute after restarting the application. There's at least one other open Stack Overflow question regarding this, although he's using a slightly different syntax than I used. If you can get to_prepare to work, I'd suggest that instead of before.
About a year later, I have finally found the answer to this question. This answer is specifically for rails 3.1. I am not sure if it is a problem in rails 3.2.
The problem occurs when setting up a model. If scaffolding is used, no helper file is generated. This would normally be in /app/helpers/staff/location_helper.rb. There are two ways to setup this file:
module Staff::LocationHelper
...
end
module Staff
module LocationHelper
...
end
end
In rails 3.1, specifically for helpers, you must use the first solution. You do not have to use it for other modules that use a namespace in other parts of the rails project. In fact, some structures in ruby require the second solution.
If you use the second solution when declaring a helper, in certain cases the Staff module in the helper file will override the module in /app/models/staff.rb. It will silently replace it with the empty Staff module in the file. This does not happen 100% of the time because helpers are not always loaded.
For one of my models I have a method:
def download_url
url = xxxxx
end
which works nicely to make /xxxx/xxxx/3
What i want to do is updated this to include an absolute URL so I can use this method in an email:
https://example.com/xxxx/xxxx/3
But I don't want to hard code. I want it to be an environment var so it works on dev & production
Emails are effectively views, and can use helpers. The model shouldn't really have any knowledge about the views - instead, you should use url_for or one of its descendant methods in the email view template to generate a URL. Those helpers can generate absolute URLs based on the location that the application is running (and associated configuration - you'll want to set config.action_mailer.default_url_options[:host] in your environment file) without having to mess with environment variables and the like.
I would define the domain as a constant in development.rb & production.rb:
APP_DOMAIN = "https://mysite.com"
And then just use this constant in your method within the model:
def download_url
"#{APP_DOMAIN}/download/#{id}"
end
It may be ugly, but it's necessary. Rails apps don't and shouldn't know their root URL. That's a job for the web server. But, hardcoding sucks...
If you're using capistrano or some other deployment method, you can define the server host in a variable and write it out to a file that you can read from the app.