ArgumentError in Users::OmniauthCallbacksController#google_oauth2
header field value cannot include CR/LF
Really unsure where this error is coming from.
I'm using ruby 2.5, Rails 5, and google-api-client 0.8.2
Any ideas how to fix or what information I can provide to make this question more informative?
Update: My logs show this when I am trying to authorize with Google's API
Google::APIClient::Request Sending API request get https://www.googleapis.com/discovery/v1/apis/calendar/v3/rest {"User-Agent"=>"hello U/1.0.0 google-api-ruby-client/0.8.2 Mac OS X/10.13.4\n (gzip)", "Accept-Encoding"=>"gzip", "Content-Type"=>""}
And from my research, CRLF is "\r\n" characters, right?
So "User-Agent"=>"hello U/1.0.0 google-api-ruby-client/0.8.2 Mac OS X/10.13.4\n
is probably the issue.
So my question would be- how do I access User Agent in my request to fix this issue with Rails 5?
When using the Google::APIClient, the generated User-Agent may contains a CRLF. It can can be overridden in constructor. Example :
Google::APIClient.new(application_name: 'Foo', application_version: '1.0', user_agent: 'Foo/1.0 google-api-ruby-client/0.8.6 Linux/4.15.0-65-generic (gzip)')
You can modify the user_agent string to remove the CR/LF. I am using Rails 4.1.8 and google-api-client version `
#api_client = Google::APIClient.new(:application_name=>"Chronos", :application_version=>0)
# work around a bug that puts a CR/LF in the user agent string
#api_client.user_agent = #api_client.user_agent.gsub("\n", "")
Update gem google-api-client to version 0.20.0. It solves the problem but requires other changes to the application
Updating the version of the google-api-client gem did the trick for me.
Related
I got this error reported to me recently from my Rails app.
mycontroller#update (ArgumentError) "invalid %-encoding (<%MYTEST)
An ArgumentError occurred in mycontroller#update:
invalid %-encoding (<%MYTEST)
These are the parameters that were passed.
Parameters : {"controller"=>"mycontroller", "action"=>"update", "id"=>"autoshell", "format"=>"txt"}
Should I be worried? I recently upgraded to Rails 4.1 and ruby 2.1.3. What is autoshell.txt?
This seems to be somebody scanning for websites vulnerable to JCE Joomla Extension Auto Shell Upload Exploit. Really nothing to worry about.
I've been seeing this error in our logs as well. I'm not concerned about it personally, but if it becomes annoying you can add this to your routes.rb file:
put '/autoshell', to: proc { [404, {}, ['']] }
That will return an empty 404 response.
i am new in ruby and rails i want to send a soap request using "savon" gem but it provide operations empty when i run this client.operations, here is my code
I am using Savon 2.3.0
ruby 2.1.0
Here is documentation of savon 2.3.0
http://rubydoc.info/gems/savon/frames
client = Savon.client(wsdl: 'https://webservice.kareo.com/services/soap/2.1/KareoServices.svc?wsdl',
:ssl_verify_mode => :none,
log: true,
pretty_print_xml: true)
puts client.operations
Thanks for help
You don't really need that. Try to call a function from your service. If that doesn't work then download SoapUI and try to create a successful call from SoapUI to your service.
In a next step you build ruby code which creates the same request as the one from SoapUI.
If that doesn't work for your come back and ask again.
Im using the Ruby Asana gem https://github.com/rbright/asana.
As per the documentation, in my controller I have:
tag = Asana::Tag.find(6498432136675)
#waiting_tasks = tag.tasks
However, this returns:
Failed. Response code = 400. Response message = Bad Request.
I have confirmed that the id is correct. If i use:
puts tag.inspect
I get the following:
#<Asana::Tag:0x007f94432af498 #attributes={"id"=>6498432136675, "created_at"=>"2013-07-14T10:05:13.070Z", "name"=>"Waiting for", "notes"=>"", "workspace"=>#<Asana::Workspace:0x007f94432aea98 #attributes={"id"=>6399696678844, "name"=>"Ministry of Crazy Ideas"}, #prefix_options={}, #persisted=false>, "color"=>"light-teal", "followers"=>[]}, #prefix_options={}, #persisted=true>
I dont understand why this is not returning the tasks as documented in the read me. If anyone can shed any light on this I would be hugely grateful.
Sounds like it's most likely a bug in the ruby gem. However, it could be an underlying API issue. Try curl -u <YOUR API KEY>: https://app.asana.com/api/1.0/tags/6498432136675/tasks - if that works, the gem isn't constructing the right URL (aka, that one). If it still returns a 400, the issue may be with the API.
I have checking the whois information for .org/.net/.ae sites. While parsing it was giving error.
This is my code part:
record = Whois.whois(url)
date = record.created_on
Its giving the following error
Whois::ParserError: Unexpected token: Access to .ORG
What is the issue here. Its working for .com URLs.
The issue has been fixed in this pull-request and I've released a new version today. Make sure to use the v3.4.4.
I have been trying to connect to a web service that is using digest authentication.
I am able to connect in Safari using user:password#service.site.com/endpoint
I have tried in Ruby and Rails to connect using HTTParty and Net:HTTP using the "basic"auth" options, but have not had any luck.
Wondering if the HTTParty/Net:HTTP "basic_auth" option is not going to be compatible with a "digest auth" service?
If not, is there another way that I might connect?
HTTParty basic auth is apparently not compatible with digest_auth. I found this Net:HTTP extension: https://codesnippets.joyent.com/posts/show/1075 and am writing a method to handle this, with the help of the Crack gem http://github.com/jnunemaker/crack:
def self.decode vin
url = URI.parse(APP_CONFIG[:vinlink_url])
Net::HTTP.start(url.host) do |http|
res = http.head(url.request_uri)
req = Net::HTTP::Get.new("/report?type=basic&vin=#{vin}")
req.digest_auth(APP_CONFIG[:vinlink_login], APP_CONFIG[:vinlink_password], res)
#response = http.request(req)
end
if #response.code == "200"
hash = Crack::XML.parse(#response.body).recursive_downcase_keys!.recursive_symbolize_keys!
end
end
Wasn't able to get to the codesnippets link given above today, but code is also available here https://gist.github.com/73102. I've used this successfully for digest authentication, but ran into problems with multiple request, getting 'Stale client nonce' errors - resolved by generating a new nonce within the digest_auth function each time it was called. Didn't find much on that when I looked, so hope this helps someone.