Working on some rails app where observing a weird issue, when there is a “#/whatever” at the end of a url, it wipes out the rest of the url.
For e.g., if we have below URL
https://www.example.com/sub/123/cou/321/something
and we add #/hello?how-are-you, like
https://www.example.com/sub/123/cou/321/something#/hello?how-are-you
and press enter, url changes to:
https://www.example.com/hello?how-are-you
On all environments. Tested this in other rails app and .NET apps where this is not observed, below are details of my ROR app:
rails 4.2.7.1, ruby 2.3.1 and many gems
Question:
How can I prevent this behaviour, as this send wrong url.referrer to server
You can't. Fragments are local to the web browser, that's their whole point. They never get sent to the server, so there is nothing you can do on the server to get them.
Related
I'm having a weird problem I cannot seem to figure out related to rails params.
I have a Controller where I permit any param. In this controller, a param (csv_type) controls which CSV file I will respond. CSV of type registration or attendance, for example.
This param is built in URL via path (e.g.: abcs_path(#abc, format: 'csv', csv_type: 'attendance') resulting in /abcs/id.csv?csv_type=attendance.
I would expect {"csv_type"=>"attendance", "controller"=>"abcs", "action"=>"show", "id"=>"45", "format"=>"csv"} but in production I get {"controller"=>"abcs", "action"=>"show", "id"=>"45", "format"=>"csv"}. csv_type is gone.
This works flawlessly locally and I get all params. Also works well on Heroku review apps. Also works well when I run locally on RAILS_ENV=production.
But in real production, it doesn't. It also doesn't work on staging which is configured with RAILS_ENV=production. Though review apps are also RAILS_ENV=production, which makes the whole thing a mystery.
Ideas:
- nginx messing up with domain (staging and production are on official domain, review app is Heroku domain, local is localhost).
- sqreen somehow intercepting this
- mime.types and https (have tried adding csv to rails, with no success). Didn't add on nginx
- some rails config on params permit (though I'm doing params.permit!) on before_action just to make sure
- some ENV variable messing up?
- can't think of anything else ???
Thanks in advance for the help!
I deployed today on 2 different AWS environments (set up identically) the same version of our app.
On our second app, I have an issue when users click on a link.
Link should redirect to my_app/module#/page and instead, it redirects to my_app/module#!/#%2Fpage
Locally and on the first app, it works fine. I look and could not find the reason why encoding is changed in this instance.
They are both rails app. nginx used on both servers if that can help
Thanks.
Issue was due to Angular version on one of my apps.
After editing the package.json file and re deployed, everything is back to normal.
issue related: URL hash-bang (#!/) prefix instead of simple hash (#/) in Angular 1.6)
I'd like to play with rails code to understand it deeper and how everything works internally. And it could be very nice to change rails code and see the changes after reloading page (by default I need to restart server), what is the right way?
you shouldn't need to restart your server just refresh your page, except for adding migrations
also you can play with your rails app interactively using the rails console similar to irb
just type rails console or rails c into your app directory
I have an app I recently upgraded to Rails 4.2.0. In this app I request an access token for a small API. In the API controller I am attempting to grab this token. I am testing with POSTman, sending a request to my local machine, running it with dev or production works perfect fine. Sending a request to the nginx phusion passenger server yields nothing, the token is nil according to the logs.
POSTman request
headers: access_token: '12345'
API controller
#access_token = request.headers['HTTP_ACCESS_TOKEN']
The headers are read in all cap with the http prefix as I read somewhere - which I can't seem to find now, that this was the proper setup. My rails 3.2 app used to read lowercase without the prefix headers, and work correctly. Once upgrading to 4.2.0, this functionality broke locally. Adding the prefix and uppercasing the read-in solved the issue locally in dev and production modes. Once deployed, however, the headers always seem to be nil.
Since I can run locally in production mode and this works, I am having a hard time figuring out what happens once this is deployed. Is this something with nginx or passenger? I am pretty new to nginx, am I missing something here? Any help you could provide would be greatly appreciated.
When using rails over an Webserver with CGI Interface, these Headers are dropped by Apache or NGIX.
It's a legacy problem. ACCESS-TOKEN and ACCESS_TOKEN would be mapped to the same CGI variable 'access_token'.
And because Dashes are more common in the header, the underscores are ignored.
I have a rails app on heroku, and a wordpress-heroku install also on heroku. I'm using the rack-reverse-proxy gem to redirect my wordpress to the /blog directory on my rails app. I followed all the instructions here:
http://rywalker.com/setting-up-a-wordpress-blog-on-heroku-as-a-subdirectory-of-a-rails-app-also-hosted-on-heroku
When I access my wordpress blog on its normal address, everything works fine. However, when I have it set up under a subdirectory of my rails app, I can't log in. I go to wp-login.php I enter my credentials, get forwarded to /blog/wp-admin.php, and then immediately I am redirected back to /blog/wp-login.php?redirect_to=http%3A%2F%2Flocalhost%3A3000%2Fwp-admin%2F&reauth=1. The only cookie that gets set is the wordpress_test_cookie, but none of the other wordpress cookies make any appearance in my browser.
I have tried many things to fix this including using rack-reverse-proxy to forward all rails traffic to wordpress, so I don't have to use a /blog subdirectory in case that was causing the problem. But the exact same behavior results. I've also determined that the :preserve_host setting in the Rack::ReverseProxy config doesn't seem to make any difference whether it's true or false.
Ideas?
A) What do you have in your wp-config.php? Should be something like this:
define('WP_SITEURL', 'http://www.DOMAIN.com/blog');
define('WP_HOME', 'http://www.DOMAIN.com/blog');
B) In the Rack::ReverseProxy settings, are you pointing to the blog (wordpress) herokuapp.com URL, not the main site (rails) URL, right? I realize my post isn't clear on that point.
I finally tracked this down to a bug in rack-reverse-proxy. The set-cookie header was being sent in an improper format, so only the first cookie was being interpreted correctly by the browser. That happened to be the wordpress test cookie. All the other (useful) ones were being thrown away, so of course I could not log in.
I plan to submit a bug and branch to rack-reverse-proxy but in the meantime I fixed it with this patch in my config.ru:
class MyReverseProxy < Rack::ReverseProxy
private
def create_response_headers(http_response)
response_headers = super(http_response)
if response_headers
if response_headers["Set-Cookie"].is_a?(Array)
response_headers["Set-Cookie"] = response_headers["Set-Cookie"].join("\n")
end
end
response_headers
end
end
# this is to make /blog show my wordpress blog
use MyReverseProxy do
reverse_proxy_options :preserve_host => false
reverse_proxy(/^\/blog(\/.*)$/, 'http://your-blog-server.com$1')
end