I have a Rails app that uses the gem Httparty. It makes a call to Stubhub's API with a base URI of https://api.stubhub.com. The app behaves as expected locally and makes successful calls. However, when deployed to Heroku I get 403 forbidden error -- it is making the request to http instead of https. Is Heroku forcing the GET request to an http endpoint? Why? How can I fix this?
Thanks!
I have been struggling with a similar issue for months now. It recently came to my attention that the SSL version could cause this timeout. Using HTTParty I resolved this like this:
HTTParty.get('url_here', ssl_version: :SSLv3).body
I am unsure as to which ssl_version token you will need, but in my case, this fixed the problem. Take a look here for a little more information about where this came from:
https://github.com/jnunemaker/httparty/issues/257
A warning: SSLv3 is not secure, but that does not stop people from continuing to use it.
Related
I am trying to follow the ruby-saml example code for doing the outbound redirect and am hitting a CORs exception.
The code in question is:
request = OneLogin::RubySaml::Authrequest.new redirect_to(request.create(saml_settings))
When I try to call this via axios, I get an OPTIONS preflight which rejects me with a 302 and
Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
So far, I have tried rack-cors, rails-reverse-proxy and a number of other things but I cannot get past this block.
Does anyone have some good instructions on how to fix this? Why is the redirect not being handled as a simple request? i.e. Why am I getting the OPTIONS preflight? Can I somehow make this a simple request?
Someone was saying that I will need to proxy through something like nginx but that seems overkill this.
rails 6, react if it matters.
The error you are experiencing is not related to SAML.
This is related to the fact that you are executing a redirection to a website which hostname mismatch the rails server hostname and the headers that are added on the request.
CORS explanation: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
You need to review your rack-cors settings as well as review if your Apache/Nginx configuration is configured properly.
https://enable-cors.org/server.html
I have been struggling for a long while trying to determine the correct approach to use the omniauth-facebook gem.
I am running my API on port 3001 while my frontend (in my case coded on ReactJS) is running on port 3000. As per what I have been researching, this is a common issue but there is not a clear answer nor documentation here. I am not expecting to use any additional SDK as I understand that this gem should handle all I need to simply login through FB.
When manually running on the browser http://localhost:3001/auth/facebook, I can see on Rails console that route is being hit and things are moving forward as expected; also, I am seeing that callback route is hit and I am getting back a JSON with UID, client and auth_token.
However, when trying to reach this through my react app, I am getting a CORS error. I am simply making an AXIOS.get(/auth/facebook) which gets routed into my API as I have configured the proxy to pass calls received on my frontend into the API. My console seems to be hit by my request as I am seeing the following:
However, on the Chrome console, I am seeing a CORS issue as per the following image:
For sure, I have already tried adding the following code snippet and still getting the same error:
Having said this, could someone answer me the following questions:
which is the expected way to trigger the initial call into /auth/facebook route? Kindly do not FW me to read the main repo doc as it does not say this solution there.
has someone solved the present issue on a way which is not by adding a link into http://localhost:3001/auth/facebook? Would this be a correct approach? It sounds weird to me.
I understand that sometimes a client will show an HTTP request as returning a 0 status code when the request fails to connect, timesout, etc, but I have never seen a server logging 0 as what it is sending back to the client.
I am running a Rails 4.2, ruby 2.2.x API. I was analyzing our logs the other day and noticed that a non-trivial number of requests were being responded with an HTTP status code of 0 by our Rails API. I have been unable to figure out why.
In some cases, it appears the request never makes it to the rails app. I only see the log message which I believe is logged by rack as to the request path and status returned. In other cases, I can see one of the early log messages we log from our application controller.
Has anyone seen such a behavior? I am not sure how to debug further without beginning to modify the standard rack middlewares that rails provides. I am not able to reproduce the situation myself; I only see this sporadically in our logs.
A bit more about our stack:
Rails 4.2.5
Ruby 2.2.3
Puma 3.4.0
We are reverse proxying with nginx, but I dont think is effecting it since the request is received by rack at least.
I realize it would probably be impossible to answer what exactly is happening here, so I am hoping instead for suggestions on how best to troubleshoot this.
Found that this is an issue with our Rails logging setup. By correlating these logs to our nginx access logs, I can see that a 302 is actually being returned to the client. This was commonly happening when the CSRF protection failed.
It looks like this is caused by a lograge (gem) bug: https://github.com/roidrage/lograge/issues/67
I have seen this behavior when requests were sent from different subdomains that were not allowed based on Access-Control-Allow-Origin. So maybe that's one possibility
I am trying to create an OData model in SAP UI5 this way:
new sap.ui.model.odata.ODataModel("http://services.odata.org/Northwind/Northwind.svc/");
but I am getting a 501 not implemented error!
could you please check what's wrong?
Thanks
As far as I can see it, the service is not really CORS-enabled. I have the same problem with my own examples here, as soon as I am not using some kind of proxy, I get this error.
The reason behind it is that when you send a complex request to the service, you'll autmatically have a so-called preflight request sent by your browser (before the actual GET) which is not a GET-Request, but an HTTP OPTIONS request.
All the odata.org sample services return a 501 error at the moment for such requests.
You can e.g. use the simpleProxyServlet which is shipped with UI5, or of course any other proxy which would solve this.
You are getting this error as your browser will refuse this request due to same Origin Policy. Here is what you should do:
Deploy the app on the same server or domain as the service that you want to call, so that both resources are in the same origin (if possible)
Disable the same-origin policy in the browser for local testing. Run Chrome by running Chrome with the following command:
[your-path-to-chrome-installation-dir]\chrome.exe
--disable-web-security --user-data-dir. Make sure that all instances of Chrome are closed before you run the command. This allows all web
sites to break out of the same-origin policy and connect to the
remote service directly.
-> Don't do this in your productive app as it imposes a security risk.
Using a proxy
The following documentation should help you understand this more and implement:
Conncting with oData Service
Request failing due to Same-Origin Policy sharing(CORS)
Please use "proxy/http/services.odata.org/Northwind/Northwind.svc", I think it's solve your problem!
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.