I'm developing an application that trying to use an unofficial HomeDepot API, the app is deployed to Heroku.
When running it locally it works well, but from the Heroku server, I occasionally get an Access Denied error from HomeDepot.
Example:
Access Denied
You don't have permission to access "http://www.homedepot.com/..." on this server.
Reference #18.8c9ec817.1613321797.55cbcde
I know that HomeDepot is blocking access from certain locations, mostly APAC, but my Heroku server is located in the US - I have looked up for the server IP and it is actually AWS, dynamically changing but always US.
Has anyone else experience the same on Heroku/AWS and can share some tips?
Thanks!
This is an Akamai (CDN provider) 403 error, like ceejayoz said, you were likely blocked for scraping or excessive requests.
Your best bet is to contact Amazon for a new IP address as this one no longer works on Akamai protected sites.
Related
I have changed the password of the digitalocean droplet then after that the website is not working at all and the api's for the mobile application is not working either.
The website and the apis aren't made by me but by different side,and they built using python-django.
Please i need your help to recover everything as i believe it's a problem with the reset password process i have done.
here is the website :
http://educationwallets.com/
here is the message i got :
502 Bad Gateway
nginx/1.10.0 (Ubuntu)
Fixed.
Just after a reboot, ssh with eduWallet user and type "supervisord" it will start the server.
Context : I have to call an externalService, which lies outside the environments hosted by us on AWS-EC2. This externalService requires IP Addresses to be whitelisted before accessing it. Since EC2 hosts IPAddresses are not guaranteed to be same and can change while replacing hosts, we decided to route the API calls through a proxy-server.
We are doing the same for some other externalServices calls as well, but those are all REST based, so we have not faced any problems while calling their APIs using rest-client or net/http.
Now, this time it's a SOAP Service and we are using Savon to access it.
I am able to download the url using "curl" on proxy server host but if I access wsdl through proxy-server from SavonClient, it fails. It gives 403 forbidden error.
irb(main):102:0* client = Savon.client do |variable|
irb(main):103:1* variable.proxy 'http://172.31.50.91:3128'
irb(main):104:1> variable.wsdl 'https://<some_url_here>'
irb(main):105:1> end
=> #<Savon::Client:……>>>
irb(main):106:0>
irb(main):107:0* client.operations
Net::HTTPServerException: 403 "Forbidden"
For other services which do not require IP whitelisting SavonClient works, whether or not proxy-server address is provided.
Any help will be appreciated. I have been struck here for long.
Thanks,
I have a website and until some time ago it was administrated by a friend of mine; recently our relationships have been reduced, so I took the entire control of the website.
I'm not really expert with some aspects in the management of a web site. Actually I would make some back-end edits and I should connect with the server of the website.
I have the host IP, a username and a password. I tried to connect using Filezilla but I receive an error message: 530 Login incorrect.
So, I contacted the domain provider, I was convinced that the domain provider was the same of the hosting provider, but they told me that it was not true and that the hosting for the website is provided by "someone else" (it could be an other hosting provider or a private web-server, for example).
I don't know what to do.
How can I connect to the server of my website? What am I missing?
p.s.: sorry for my bad english
I think you might be pointing filezilla at port 80. Try pointing at the ftp port (21 probably.) If this doesn't work it could be that the hosting uses a non standard port.
If in doubt get some support from the hosting company. Only they know how they are set up. If the use something like cpanel you can access files through that. They may be reluctant to help if you can't prove the site is yours. Usually by using the email address you set up when you bought the hosting.
And no, the domain provider does not have to be the same as the hosting provider. My domains are hosted at godaddy and I have odd bits of hosting all over the place ;)
Well. I created reference, tested on local machine all is well. Deployed solution to production server and here we go:
An error occurred while trying to make a request to URI
This could be due to attempting to access a service in a cross-domain
way without a proper cross-domain policy in place, or a po
From what I gathered - it's security measure to prevent something (not sure what). Well. I can't make provider to put clientaccesspolicy.xml and crossdomain.xml.
What is my options? Looks like either running Silverlight app in elevated mode or.. ?
I don't want to require elevated trust.
The only way I know is to call my server and make call to webservice from my server returning data back to client. Seems like too much overhead. Is there any better way? Really frustrating.
I'm afraid your options are limited here. In compliance with Same Origin Policy the cross domain policy file is a must. Here you can find an example why. Personally I would go down the route of proxying the remote web service via your hosting server if you can't influence the provider.
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.