ELB target group's health check is failing with status code 403 forbidden after upgraded rails to rails 6. However health check is working in development but not on AWS cloud.
Health check is succeed with rails 5 but not with rails 6.
Any help would be greatly appreciated.
This happens because of a new feature in Rails 6: host authorization. It checks whether the incoming request has correct hostname, and in case it doesn't, it returns 403.
AWS ELB doesn't set the Host header when it accesses the health check endpoint, which makes it fail.
You can fix the problem either by disabling the feature (config.hosts.clear) by adding the web server internal IP (ELB accesses it with the internal one) to the allowed hosts, like this:
config.hosts = ["example.org", IPAddr.new("10.0.99.0/24")]
Related
I'm trying to configured an Azure Application Gateway in front of a web app. The web app is empty for now, only a single page to verify its running. I've added a custom domain and dns settings, verified in the network settings of the webapp. I've setup the AG following a few different links as I couldn't get a working example from a single source. I'm at the point now where my health checks are returning a 301. The lister is using port 80 as I have not setup the ssl yet. The app custom domain has no ssl binding either. The network security group has the default settings. I've checked the webapp before adding the private ip and it was fine, its just an empty page. So i'm wondering what could be causing the 301. Anyone have an idea what could be causing that or some further links I can check?
Thanks.
Resolved. The webApp had Https Only turned on in the settings, that was the cause of the 301. Doh!
I am trying to configure JDBC but kept getting the same error I am getting using snowsql:
250001 (08001): Failed to connect to DB. Verify the account name is correct: JG3409.canada-central.azure.snowflakecomputing.com:443. 000403: 403: HTTP 403: Forbidden
If the error message is unclear, enable logging using -o log_level=DEBUG and see the log to find out the cause. Contact support for further help.
Goodbye!
I have configured the config file, and I have double checked the account, company, region, reset password to only use alphanumeric.
I have used both forms of the URL
The only possibility is that I am using a trial account, but I can't imagine that this would limit external non-browser connections?
I use a simple user/password, I have whitelisted my IP and I don't have a problem with a proxy or a firewall. I can successfully connect using a browser.. using:
https://app.snowflake.com/canada-central.azure/jg63409
Important contents of the config file:
[connections]
accountname=JG3409
#accountname=uegxydq-pz20606
region=canada-central.azure
username=ASHSNOWFLAKE
any ideas?
Your account is not JG3409 but JG63409 based on this link:
https://app.snowflake.com/canada-central.azure/jg63409
Try in your browser:
https://jg63409.canada-central.azure.snowflakecomputing.com
I found out using snowcd that my computer could not connect via my home router.
When I used my personal hotspot on my (5G) phone, snowcd passed all the tests immediately. The problem then arose how to adjust the network security policy to allow a CIDR block of network addresses through since my phone uses a new address every time I connect, and I can't edit the policy to allow my phone while connected via my phone (for obvious reasons)
Catch 22
123.45.0.0/16 is not accepted in the new Snowflake UI, and 0.0.0.0 doesn't work for me, but the documentation gave me a clue.. the new UI doesn't separate by commas, so I switched to the old UI and voila!
Incidentally the OLD UI uses the same URL as SnowSQL so I picked up my error in my account number there as well (although I should have seen it earlier).
Diabolical but thanks #Sergiu too!
I am currently connecting to the Twitter User Stream API but it seems that I am not getting updates on my production environment (https), it does work on my staging server though.
Some information that I checked myself already:
- The 2 environments are on the same server so it can not be an IP block.
- A code issue would be possible but unlikely since it works on staging but not on production
- Nginx is configured correctly to allow this on https since it worked before
the only thing I can think of is that Twitter blocked our https connection, we reached a Twitter cap or Twitter got problems streaming to Https.
Is there anyone that encountered this before or that can help me with this?
It seems that this was caused by Twitter who puts an internal (badly documented) limit on connections from a webservice to their UserStream service. (This connection limit is around 20 - 30 connections I think).
A solution that I use now is to poll every 90 seconds to their REST api.
Everything works fine in a development/localhost environment.
When deploying to heroku, using sandbox/test credentials on a new app, and creating a new payment I am getting
A PayPal::SDK::Core::Exceptions::UnauthorizedAccess occurred in orders#create:
Failed. Response code = 401. Response message = Unauthorized.
Again, everything thing works in a development environment
Should I permit any specific domains (like in Facebook integration)?
If you are running a Rails application on a public server, there is quite a chance that the Rails environment is set to "production".
If you further use the config/initializers/paypal.rb and config/paypal.yml generated by the Paypal API SDK's standard generator, then:
the initializer loads configuration for the current Rails environment, which is "production"
and in the production configuration one important line presumes that you want to run on the live API
So most probably you are attempting to communicate with the live API without knowing it. Changing the line to mode: sandbox should make you happy.
I had this problem and I called Paypal. It was a config problem in my account.
To resolve I went to https://developer.paypal.com, logged in, Then clicked on Dashboard Then on my account (left) The Direct credit cards has a grey x next to it so you have to click the link next to it that reads Enable live credentials Once you do this you have to answer some verification questions then they approve your account then your live and the unauthorized error goes away.
We just launched a rails app on heroku and see a lot of connection timeouts to the api.
We have a connection timeout of 10 sec.
Is it a normal behavior or is it because of too many hits? All queries are authenticated as a user.
We query friends/ids and followers/ids only.
We see also timeouts in our reverse auth query done by the same app.
Do somebody already had something like that?
EDIT
Having a support ticket, they told me they were looking with twitter's engineers to avoid blacklist.
It appears this is due to Twitter blacklisting Heroku's primary IP addresses. If you are having this issue, please file a ticket with Heroku and comment on this Twitter discussion: https://dev.twitter.com/discussions/20185
When you are using the Twitter gem (?) sometimes the connection timeout happens when your DNS server can't resolve the IP of api.twitter.com fast enough. Check your DNS settings # /etc/resolv.conf
Most the PaaS are using the Google ones (4.4.4.4 or 8.8.8.8) which are rate limited and sometimes very slow...resulting in connection timeouts.
Got the same problem running a Rails app on Cloud66/DigitalOcean. Changed the DNS to some more local ones and the Twitter gem performance like a jaguar.