I'm trying to return a custom error message from http 500 responses. When testing it locally it provides the custom response, but when running on Heroku it gives a generic "Internal Server Error" response. Does Heroku override 500 error responses? And if so, is there a way to have it use the custom one I sent?
You need to upload your custom error messages and maintenance pages to an external source such as S3 for example. You then need to add to your apps config the location of your error pages so they can be called when needed.
heroku config:add \
ERROR_PAGE_URL=http://s3.amazonaws.com/your_bucket/your_error_page.html \
MAINTENANCE_PAGE_URL=http://s3.amazonaws.com/your_bucket/your_maintenance_page.html
See the Heroku docs for more info: https://devcenter.heroku.com/articles/error-pages
Related
I'm attempting to use the REST API provided by WooCommerce to generate the Customer Secret and Customer Key values so that it could be used to invoke other WooCommerce REST APIs. I referred the documentation about generating the key values and managed to get it working using a mock endpoint in Postman used for the call_back URL in the API as mentioned in the document.
I created a POST service in my backend server and managed to setup a SSL certificate in the local environment with a domain mapped in hosts file in /etc directory. I ran the backend service and invoked the callback url through Postman and it worked. Then I used that as the call_back URL in the actual WooCommerce Auth endpoint to programatically generate the keys and save it in my DB. But I'm getting
"Access Denied" - Error: A valid URL was not provided..
When I checked the browser through devtools -> network noticed that there is a 401 Unauthorize error.
Here is the sample GET URL that is uesd for WooCommerce API key generation
http://localhost/woocommerce/wc-auth/v1/authorize?app_name=<SOME_NAME>&scope=read_write&user_id=36&return_url=http://localhost/woocommerce/&callback_url=https://foo.bar.dev:44329/api/services/app/woo_commerce_auth/6/callback
callback_url = https://foo.bar.dev:44329/api/services/app/woo_commerce_auth/6/callback
When the callback_url is a mock url generated using Postman it works fine
callback_url = https://513ca6ab-db16-4635-8d0b-9159e3b1e187.mock.pstmn.io/api/services/app/woo_commerce_auth/6/callback
Any clue why this happens, I could not find a way to troubleshoot this issue. Appreciate the help.
Hi posting this for future reference, and hope it would help others who face this problem as well.
Things to keep in mind when setting the callback_url,
Non HTTPS URL endpoint are not allowed.
URL should not be a localhost url (e.g localhost/callback would give an invalid URL error)
URL should not contain port number (e.g localhost:4320/callback or foo.bar.dev:4892/callback are invalid)
Callback URL should be a POST url
If an error such as Error: An error occurred in the request and at the time were unable to send the consumer data. is given after checking all the above check the backend service code related to the callback_url (I had a 500 server error which triggered this, it was not a WooCommerce issue)
Also a tool such as ngrok would be really helpful to setup an HTTPS endpoint in your local environment to test this.
I have one server on which Apache and Tomcat both are installed to run my Wordpress and Java application respectively. Both are on same ip address and using same domain https://www.example.com only port number is different.
Wordpress is running on default port while Tomcat is runing on 8443.
A rest api on Tomcat https://www.example.com:8443/myApi.html is working fine from postman, but when calling from wordpress using ajax, it returns error 403 forbidden response.
I am stuck on searching its solution but failed.
Please help me out to solve this issue.
Thanks
You cannot use a different port, even when using the same domain. This breaks the Same origin policy.You can however use JSONP if you have access to both the daemon and the requesting site. If data needs to be returned, then the daemon needs to support a callback query parameter and return it properly formatted.
please see 1) https://stackoverflow.com/a/2099771
https://stackoverflow.com/a/2099784
I set up a REST API in AWS with a PUT method to upload files to an S3 bucket. The "Authorization" field in the Method Request is set to NONE. I'm calling the API in Python like so:
file = {"file": open('file.jpg', 'rb')}
requests.put(https://api-id.execute-api.us-east-1.amazonaws.com/Prod/bucketname/filename, files=file)
However, each time this command runs, it returns the error:
"403 Client Error: Forbidden for url: https://api-id.execute-api.us-east-1.amazonaws.com/Prod/bucketname/filename"
This doesn't make sense to me; authorization is set to NONE, so anybody should be able to call the API - why am I getting "Forbidden"? Also, the request works perfectly fine in Postman - I am able to call the API and upload the file and it returns "200 Successful".
I've searched other posts on Google and StackOverflow to no avail. What is going on?
Figured it out, I was sending Binary files up to the gateway without adding those file types to the "Binary File Types" section in Settings. For some reason this resulted in a 403 Forbidden Error (even though it wasn't an authentication issue at all).
I am trying to replicate a scenario where s3fs command error out with return code 503 for the request made. How can I recreate this scenario
I created a node.js application which will return 503 status code.
How to specify HTTP error code?
Now I use the endpoint of node js application in s3fs command I get the desired result.
I have set up a dependency in my Gradle build script, which is hosted on Bitbucket.
Gradle fails to download it, with error message
Could not HEAD 'https://bitbucket.org/....zip'. Received status code 403 from server: Forbidden
I looked into it, and it seems that this is because :
Bitbucket redirects to an amazon url
the Amazon url doesn't accept HEAD requests, only GET requests
I could check that by testing that URL with curl, and I also got a 403 Forbidden when sending a HEAD request with curl.
Otherwise, it could be because Amazon doesn't accept the signature in the HEAD request, which should be different from the GET one, as explained here.
Is there a way around this ? Could I tell Gradle to skip the HEAD request, and go straight to the GET request ?
I worked around the problem by using the gradle-download-task plugin, and manually writing caching as explained here