I have a ruby-on-rails application running locally on a WEBrick server. I am using Postman to trigger HTTP Methods (POST, GET, etc) in order to check if any error page is shown to the users. The figure below shows one of the error pages found when performing a POST to the home page:
WEBrick Error page
As one can note, the physical path to the application directory is disclosed: /home/dennis/dunbarwebsite
Leaking this kind of information may help one fine-tune attacks against the application. Hence, I would like to know if it is possible to forward this error page to a custom one, like the custom redirection to errors 404 and 500.
Thanks in advance,
Dennis.
That error page only appears in development mode.
Add a catchall route at the end of routes.rb:
match "*path", to: redirect('/'), via: :all
Related
I have a rails app in which I would like /500 to route to a regular page. How do I configure the app so that when 500 errors occur, the app does not look for the error page at /500.html but rather at some other filename I specify?
I understand how to make custom error pages. My concern is around at what route those pages are reached. I do not want [root]/500 to go to an error page. I want the /500 page to live somewhere else, and am hoping to handle that within my rails app rather than through external config.
I'm working on a Rails application that works with data via the Shopify API, however it has just started giving me 500 errors when certain resources are requested via a proxy (as set in the app settings in Shopify).
The request is along the lines of:
/app/my-application/customers/1234.json
however the error log on Heroku is showing a GET request to:
/app/my-application/cusotmers,1234.json
I'm using the Shopify/shopify_api gem which was recently updated, otherwise nothing else in the config/routes has changed since this error began occurring.
Any help or pointers greatly appreciated!
I'll happily provide more information if anything relevant is missing above.
This was a bug in Shopify's service to proxy requests to applications.
I have just deployed a fix for the issue. I take full responsibility for the issue, and will try to improve our tests to avoid similar issues in the future.
I've got a RESTful resource (let's say posts) that excludes the index action. When I go to /posts, ActionController::MethodNotAllowed is raised because GET requests at that URL have been excluded. That much makes sense.
The problem is that in the production environment, that URL just generates a white screen in the browser. I can see ActionController::MethodNotAllowed being raised in the production log. I would expect that this would also cause a 404 or 500 error so that the error pages in the public directory would serve a pretty error page to the client.
Does this cause a different HTTP status code? How can I handle this?
I'm not positive about what the error might be, but you should get Firebug and check what the HTTP response code coming back is.
To get around the issue, you could do one of two things:
Don't disallow that page in the routes, but have the only code in that method do a redirect to an appropriate page.
Add a custom route that overrides GET /posts, which points to your desired controller.
i get this exception
ActionController::MethodNotAllowed: Only get requests are allowed.
please can any one give solution for this
This error means you are trying to post/put/delete to a path that only accepts GET requests. You need to confirm that your route and the path and/or form method you are using match up.
This error occurs when you have defined a standard route and a client is trying to connect to the route using a HTTP method different than GET or POST.
Usually, this is caused by clients using the Microsoft Office Protocol Discovery. These clients send an OPTION request which is not supported by Rails.
You can fix the problem in multiple ways:
ignore the error in your production environment
prevent the error using a before_filter and head 406 in your controller
rescue the error using rescue_from in your controller
prevent the error filtering the request via Rack Middleware
prevent the error blocking non GET/POST/HEAD requests using your webserver
I personally prefer the last option, but it requires you to have administration privileges on the server. Otherwise, the Rack Middleware option is the most efficient way to filter unexpected requests.
How are you trying to get to this page? It looks like you are trying to do some other kind of RESTful call (put, post, delete) and that method. A code snipped of that controller would be really helpful to diagnose the problem.
We have a super RESTful web service running well on two dev machines and a test 2k3 server. We're trying to get the same service running on two other offsite dev boxes. Whenever those two new, offsite boxes attempt a PUT request to 'Sessions' Resource (i.e Controller) (on localhost), IIS returns :
"Path 'PUT' is forbidden"
We turned on the MVC Route debugger and it appears that something between the front porch and the routing engine is gobbling up anything destined for http://localhost/OurAPI/Sessions.
We change the controller to UserSessions or even Session and problem goes away!
Any ideas?
When it happens in my application is a routing problem, check your routes.