I have the devise gem to enable authorisation and authentication of admin users to my web app. However once i try to access blog.xxxx.com/admins/sign_up i get an application error. Below are the contents of my production.log file
I, [2016-05-24T06:30:33.215786 #21746] INFO -- : Started GET "/blog/xmlrpc.php" for 89.248.174.4 at 2016-05-24 06:30:33 -0400
F, [2016-05-24T06:30:33.220309 #21746] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/blog/xmlrpc.php"):
actionpack (4.2.2) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
actionpack (4.2.2) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.2.2) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.2.2) lib/rails/rack/logger.rb:20:in `block in call'
activesupport (4.2.2) lib/active_support/tagged_logging.rb:68:in `block in tagged'
activesupport (4.2.2) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (4.2.2) lib/active_support/tagged_logging.rb:68:in `tagged'
railties (4.2.2) lib/rails/rack/logger.rb:20:in `call'
actionpack (4.2.2) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.6.4) lib/rack/methodoverride.rb:22:in `call'
rack (1.6.4) lib/rack/runtime.rb:18:in `call'
activesupport (4.2.2) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
rack (1.6.4) lib/rack/sendfile.rb:113:in `call'
railties (4.2.2) lib/rails/engine.rb:518:in `call'
railties (4.2.2) lib/rails/application.rb:164:in `call'
puma (3.4.0) lib/puma/configuration.rb:224:in `call'
puma (3.4.0) lib/puma/server.rb:569:in `handle_request'
puma (3.4.0) lib/puma/server.rb:406:in `process_client'
puma (3.4.0) lib/puma/server.rb:271:in `block in run'
puma (3.4.0) lib/puma/thread_pool.rb:114:in `call'
puma (3.4.0) lib/puma/thread_pool.rb:114:in `block in spawn_thread'
This log message is unrelated to your application or you trying to sign in.
It just tells you that someone tried to request the route /blog/xmlrpc.php and your application was not able to answer on that route. It is basically just a 404 not found message.
Why to people (or bots) try to request /blog/xmlrpc.php on random servers? Because the /blog/xmlrpc.php route allows attacks against some Wordpress versions. And an attacker is searching for victoms by scanning IP ranges.
It is safe to ignore this kind of requests. The only think you might want to ensure is that your application is correctly configured and responses with a proper 404 not found (not a 500 internal server error).
Simply someone is trying to call some URLs of your website to find... Well, something. It might be even a bot. Anyway, this is not a problem at all.
Related
I see this error when I load any page on my website:
Started GET "/assets/star-rating.min.js.map" for ::1 at 2018-01-26 08:18:34 -0500
ActionController::RoutingError (No route matches [GET] "/assets/star-rating.min.js.map"):
web-console (2.0.0.beta3) lib/action_dispatch/debug_exceptions.rb:22:in `middleware_call'
web-console (2.0.0.beta3) lib/action_dispatch/debug_exceptions.rb:13:in `call'
actionpack (4.2.2) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.2.2) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.2.2) lib/rails/rack/logger.rb:20:in `block in call'
activesupport (4.2.2) lib/active_support/tagged_logging.rb:68:in `block in tagged'
activesupport (4.2.2) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (4.2.2) lib/active_support/tagged_logging.rb:68:in `tagged'
railties (4.2.2) lib/rails/rack/logger.rb:20:in `call'
actionpack (4.2.2) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.6.4) lib/rack/methodoverride.rb:22:in `call'
rack (1.6.4) lib/rack/runtime.rb:18:in `call'
activesupport (4.2.2) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
rack (1.6.4) lib/rack/lock.rb:17:in `call'
actionpack (4.2.2) lib/action_dispatch/middleware/static.rb:113:in `call'
rack (1.6.4) lib/rack/sendfile.rb:113:in `call'
rack-cors (0.4.1) lib/rack/cors.rb:81:in `call'
railties (4.2.2) lib/rails/engine.rb:518:in `call'
railties (4.2.2) lib/rails/application.rb:164:in `call'
rack (1.6.4) lib/rack/deflater.rb:35:in `call'
rack (1.6.4) lib/rack/content_length.rb:15:in `call'
puma (3.6.2) lib/puma/configuration.rb:225:in `call'
puma (3.6.2) lib/puma/server.rb:578:in `handle_request'
puma (3.6.2) lib/puma/server.rb:415:in `process_client'
puma (3.6.2) lib/puma/server.rb:275:in `block in run'
puma (3.6.2) lib/puma/thread_pool.rb:116:in `call'
puma (3.6.2) lib/puma/thread_pool.rb:116:in `block in spawn_thread'
Rendered /Users/jeremylopez/.rvm/gems/ruby-2.2.3#awaken/gems/web-console-2.0.0.beta3/lib/action_dispatch/templates/rescues/_trace.html.erb (2.3ms)
Rendered /Users/jeremylopez/.rvm/gems/ruby-2.2.3#awaken/gems/web-console-2.0.0.beta3/lib/action_dispatch/templates/rescues/routing_error.html.erb within rescues/layout (452.2ms)
Processing by ErrorsController#internal_server_error as HTML
but I have no idea where it's being called. Does anyone have a good method of tracing this to find out whey it's trying to load this asset on all pages?
Could you provide more information on your asset pipeline? If you're doing everything through sprockets then check application.js - you can use process of elimination to see which require it comes from.
If you're loading scripts from a lot of different sources, you could use the network tab of your browser's developer tools, and see if these requests originate right after any particular script.
That's very wired problem but need refactoring that also tough for finding where from called this.
That's mean any gem or any file are dependent or linked to this file or application.js requiring this star-rating.min.js.map, I have searched on the Google writing star-rating.min.js.map this but not found any file over the Google which match this star-rating.min.js.map.
If you find any file within your application which calling this then you must remove or comment out this.
I think you understood the point.
I have a rails app, where users can upload files (using paperclip). When uploading large files, the user is redirected to a 500 error page, and this only happens remotely; locally the user is redirected to the view of the new model, as expected. Moreover, despite the error page redirection, the model and its associated file were successfully uploaded and created.
Since it happens only with large files, I suspect it's due to a request timeout, but I'm using puma which doesn't enforce such timeouts.
That's the application log, the puma logs don't show anything abnormal.
D, DEBUG -- : SQL (0.4ms) INSERT INTO "posts" [...]
D, DEBUG -- : (0.9ms) COMMIT
D, DEBUG -- : (0.1ms) BEGIN
D, DEBUG -- : (0.1ms) COMMIT
I, INFO -- : Started GET "/500.html" for [...]
F, FATAL -- :
ActionController::RoutingError (No route matches [GET] "/500.html"):
actionpack (4.2.6) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
actionpack (4.2.6) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.2.6) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.2.6) lib/rails/rack/logger.rb:20:in `block in call'
activesupport (4.2.6) lib/active_support/tagged_logging.rb:68:in `block in tagged'
activesupport (4.2.6) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (4.2.6) lib/active_support/tagged_logging.rb:68:in `tagged'
railties (4.2.6) lib/rails/rack/logger.rb:20:in `call'
actionpack (4.2.6) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.6.4) lib/rack/methodoverride.rb:22:in `call'
rack (1.6.4) lib/rack/runtime.rb:18:in `call'
activesupport (4.2.6) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
rack (1.6.4) lib/rack/sendfile.rb:113:in `call'
railties (4.2.6) lib/rails/engine.rb:518:in `call'
railties (4.2.6) lib/rails/application.rb:165:in `call'
puma (3.6.0) lib/puma/configuration.rb:225:in `call'
puma (3.6.0) lib/puma/server.rb:578:in `handle_request'
puma (3.6.0) lib/puma/server.rb:415:in `process_client'
puma (3.6.0) lib/puma/server.rb:275:in `block in run'
puma (3.6.0) lib/puma/thread_pool.rb:116:in `block in spawn_thread'
I've found an answer in the nginx log: it was a timeout indeed. Increasing proxy_read_timeout in nginx.conf solved the issue (the default is 60).
I randomly see a No route matches [GET] "/" error in the logs of an app. Here is the output.
[LG53P2]2016-10-25 02:46:20 +0000 severity=FATAL, ActionController::RoutingError (No route matches [GET] "/"): FATAL
[LG53P2] actionpack (4.2.7.1) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
[LG53P2] actionpack (4.2.7.1) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
[LG53P2] railties (4.2.7.1) lib/rails/rack/logger.rb:38:in `call_app'
[LG53P2] railties (4.2.7.1) lib/rails/rack/logger.rb:22:in `call'
[LG53P2] actionpack (4.2.7.1) lib/action_dispatch/middleware/request_id.rb:21:in `call'
[LG53P2] rack (1.6.4) lib/rack/methodoverride.rb:22:in `call'
[LG53P2] rack (1.6.4) lib/rack/runtime.rb:18:in `call'
[LG53P2] activesupport (4.2.7.1) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
[LG53P2] actionpack (4.2.7.1) lib/action_dispatch/middleware/static.rb:120:in `call'
[LG53P2] rack (1.6.4) lib/rack/sendfile.rb:113:in `call'
[LG53P2] actionpack (4.2.7.1) lib/action_dispatch/middleware/ssl.rb:24:in `call'
[LG53P2] skylight (0.10.5) lib/skylight/middleware.rb:61:in `call'
[LG53P2] railties (4.2.7.1) lib/rails/engine.rb:518:in `call'
[LG53P2] railties (4.2.7.1) lib/rails/application.rb:165:in `call'
[LG53P2] puma (3.4.0) lib/puma/configuration.rb:224:in `call'
[LG53P2] puma (3.4.0) lib/puma/server.rb:569:in `handle_request'
[LG53P2] puma (3.4.0) lib/puma/server.rb:406:in `process_client'
[LG53P2] puma (3.4.0) lib/puma/server.rb:271:in `block in run'
[LG53P2] puma (3.4.0) lib/puma/thread_pool.rb:114:in `call'
[LG53P2] puma (3.4.0) lib/puma/thread_pool.rb:114:in `block in spawn_thread'
The app is private and used by a really small number of people and none of the users have experienced this error ( not able to access the root_path ). I never see it outside the logs. I assume this could be a bot doing a scan.
The routes.rbfile contains the right information:
constraints subdomain: "the_subdomain" do
scope "(:locale)", locale: /#{I18n.available_locales.join("|")}/ do
root to: 'my_controller/static#home'
end
.... other routes
end
And the rake routes output seems normal:
root GET /(:locale)(.:format) my_controller/static#home
At this point the app is regularly used and this bug is just a glitch in the logs nothing more. But I think it worth asking!
Any idea about what can cause this error and how or if I can do something about it?
With the given informations nginx proxies all requests to the Rails app. If the host is accessed directly via IP-Address or custom DNS entries, the first app in line gets the request.
Because the root_path is restricted to a subdomain, the given routing error occours.
There are multiple solutions. First, restrict nginx to route only known subdomains to the Rails app. Second, add a route outside the constraint and log such requests with a special controller and action. Third, redirect unknown subdomains to a special site.
I´m checking my Ruby on Rails log files and I wonder why do I have request like this one (my app doesn´t have any request like this):
I, [2015-07-13T11:45:26.004933 #22638] INFO -- : Started GET "/Ringing.at.your.dorbell!" for 186.116.51.54 at 2015-07-13 11:45:26 +0000
F, [2015-07-13T11:45:26.005954 #22638] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/Ringing.at.your.dorbell!"):
actionpack (4.0.0) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
actionpack (4.0.0) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.0.0) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.0.0) lib/rails/rack/logger.rb:21:in `block in call'
activesupport (4.0.0) lib/active_support/tagged_logging.rb:67:in `block in tagged'
activesupport (4.0.0) lib/active_support/tagged_logging.rb:25:in `tagged'
activesupport (4.0.0) lib/active_support/tagged_logging.rb:67:in `tagged'
railties (4.0.0) lib/rails/rack/logger.rb:21:in `call'
actionpack (4.0.0) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.5.2) lib/rack/methodoverride.rb:21:in `call'
rack (1.5.2) lib/rack/runtime.rb:17:in `call'
activesupport (4.0.0) lib/active_support/cache/strategy/local_cache.rb:83:in `call'
railties (4.0.0) lib/rails/engine.rb:511:in `call'
railties (4.0.0) lib/rails/application.rb:97:in `call'
puma (2.10.1) lib/puma/configuration.rb:74:in `call'
puma (2.10.1) lib/puma/server.rb:490:in `handle_request'
puma (2.10.1) lib/puma/server.rb:361:in `process_client'
puma (2.10.1) lib/puma/server.rb:254:in `block in run'
puma (2.10.1) lib/puma/thread_pool.rb:96:in `call'
puma (2.10.1) lib/puma/thread_pool.rb:96:in `block in spawn_thread'
This just looks like someone is poking your system with a script, or just poking to see if that URL exists. Have you double checked that you're serving up the proper 404 response?
I generated rails application and I got this message out of box. I don't know what service-worker.js is but I assume it can be bundled with some default gem?
Started GET "/service-worker.js" for 127.0.0.1 at 2015-07-21 19:48:33 +0200
ActionController::RoutingError (No route matches [GET] "/service-worker.js"):
actionpack (4.2.3) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
web-console (2.2.1) lib/web_console/middleware.rb:39:in `call'
actionpack (4.2.3) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.2.3) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.2.3) lib/rails/rack/logger.rb:20:in `block in call'
activesupport (4.2.3) lib/active_support/tagged_logging.rb:68:in `block in tagged'
activesupport (4.2.3) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (4.2.3) lib/active_support/tagged_logging.rb:68:in `tagged'
railties (4.2.3) lib/rails/rack/logger.rb:20:in `call'
actionpack (4.2.3) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.6.4) lib/rack/methodoverride.rb:22:in `call'
rack (1.6.4) lib/rack/runtime.rb:18:in `call'
activesupport (4.2.3) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
rack (1.6.4) lib/rack/lock.rb:17:in `call'
actionpack (4.2.3) lib/action_dispatch/middleware/static.rb:116:in `call'
rack (1.6.4) lib/rack/sendfile.rb:113:in `call'
railties (4.2.3) lib/rails/engine.rb:518:in `call'
railties (4.2.3) lib/rails/application.rb:165:in `call'
rack (1.6.4) lib/rack/lock.rb:17:in `call'
rack (1.6.4) lib/rack/content_length.rb:15:in `call'
rack (1.6.4) lib/rack/handler/webrick.rb:88:in `service'
/home/emkacf/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:138:in `service'
/home/emkacf/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:94:in `run'
/home/emkacf/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:294:in `block in start_thread'
I assume that is from another application which uses webworkers. If you are using Firefox, go to menu > web developer > service workers and unregister webworker from there (That's the one way to do it). The other application will register it again if needed.
This coming from client-side so it's from a service-worker that has been registered in the browser.
Open DevTools and run navigator.serviceWorker.getRegistration().then(r => r.unregister()) in your console to disable it.
I fixed same problem by this gem .
1) Add gem 'serviceworker-rails' to Gemfile
2) Run bundle install in console
3) Run rails g serviceworker:install in console
4) Add match '/offline.html' string to config/initializers/serviceworker.rb
5) Create file (even empty will be enough) public/offline.html
Thats it. After these steps the error message gone.