I have a golang API app that is currently serving double-duty as a Single Page App server with static content using the method shown here: https://hackandsla.sh/posts/2021-11-06-serve-spa-from-go/
Everything is working great in terms of navigation until users try to refresh URIs with encoded JSON in them. For example:
/licenses
will refresh file and draw the page as it would normally have appeared through internal history.push()
/licenses/show/%7B"options":%7B"container":"home","field":"date","order":"desc"%7D,"license":"00001a"%7D
will cause the 500 error.
I did the initial development with IIS as a web server so these Refresh errors never happened in that environment. And when the server is ready to be deployed I plan to use Caddy and reverse proxy the API and am assuming it will handle the Refreshes with the same aplomb as IIS.
But for now I am hoping to run tests against my simple server so I'd like to solve this issue out of curiosity in addition to development expediency.
Bottom line: What cause golang http.ListenAndServe to return 500 errors?
UPDATE:
As I need to be able to test and hand off for others I have converted to a querystring which http.ListenAndServe is happy with:
/licenses/show/%7B"options":%7B"container":"home","field":"date","order":"desc"%7D,"license":"00001a"%7D
causes 500 error
/licenses/show?state=%7B"options":%7B"container":"home","field":"date","order":"desc"%7D,"license":"00001a"%7D
works fine
I am currently testing the changes for version 4.0 of the protocol for PSD2 using Direct Integration.
I am running under Visual Studio using a localhost website address.
When calling the SagePay payment endpoint with ThreeDSNotificationURL set as a localhost address (http://localhost:15536/Payments/ThreeDResponse) I receive the following error '3228 : The ThreeDSNotificationURL field format is invalid.'
If I change this field to a fully qualified domain (http://www.google.com) I no longer receive the error, but can't complete my testing.
Using localhost for the termurl in version 3.0 of the protocol works as expected.
I was attempting to work locally like your self and receiving the same issue. After speaking with support they confirmed that they will not accept "localhost". Also, the documentation suggests that HTTPS is a requirement, so this might also be a blocking factor.
I think someone suggested using ngrok as a means of tunneling external requests into your localhost, which is a good method to continue development locally whilst also being visible externally to services like SagePay.
Once I got passed the above issue, I got several more errors for other missing required fields as listed here; https://www.sagepay.co.uk/support/38/psd2-under-direct-integration (note that if BrowserJavascriptEnabled is true all conditional fields are then required)
Did you URL encode the ThreeDSNotificationURL in your post?
I send it like that and it is ok:
sb.Append(HttpUtility.UrlEncode("https://www.clientdomian.com/ac/ThreeDSNotificationURL.aspx"));
I run the site on my local IIS for development.
I recently had this issue and I wanted to document it here, because searching for this issue gives very little in terms of results.
I was getting this error code when i switched my Opayo/SagePay extension (MageNest SagePay for Magento) to 3ds2.
As it turns out, the full URL wasn't being sent. It was trying to send sagepay/direct/postBack?form_key=HZuYxgiEq9w2CNFB and NOT https://www.example.com/sagepay/direct/postBack?form_key=HZuYxgiEq9w2CNFB. It's partly my fault because there was a domain field in the config which was empty (it's not like the domain can't be retrieved automatically, huh) and partly the vendors fault because it was very badly documented.
So while this is a different problem for a different platform, I hope this helps someone.
I am in a corporate env so I have to use a proxy to reach servers. This works well in postman and in browsers. What I can't reach is localhost in postman but I can reach localhost in the browser.
I am running Postman for Linux Version 6.0.9. I have tried reaching localhost:9082/rest/myapi.... and 127.0.0.1:9082/rest/myapi with both global proxy and system proxy turned on and with either turned on and with non turned on. In all cases I am not able to reach localhost.
What I get as an response is an error page from the proxy server! Someway the call gets out on the network instead of being kept on my machine.
The postman console:
My request headers are:
Cache-Control →no-cache
Connection →Keep-Alive
Content-Length →986
Content-Type →text/html; charset=utf-8
Pragma →no-cache
Proxy-Connection →Keep-Alive
My response headers are:
cache-control:"no-cache"
pragma:"no-cache"
content-type:"text/html; charset=utf-8"
proxy-connection:"Keep-Alive"
connection:"Keep-Alive"
content-length:"986"
My response body is an html page.
How can I make a call to localhost work with postman?
I was having similar issue with HTTP calls to local ASP.NET Core Web API apps. Changing the proxy settings didn't fix it for me.
Finally fixed it by turning off File > Settings > General > SSL Certificate Verification
I have the same issue. What works for me is:
Open File -> Settings -> Proxy
Then, enable proxy and put 127.0.0.1 : 80, if your web server runs on 80.
In the git thread, they say it is a known issue, so hopefully it will get resolved soon.
I solved this by Turning off System proxy of Postman.
Open File -> Settings -> Proxy
Then Turn off Use System Proxy
#Menuka Ishan Answer is correct. But in mac only if we change the turn off proxy won't work. You need to turn off the SSL Certificate verification also you need to disable.
I found a temporary solution:
In terminal, go to the directory where postman is installed and add:
machine#dev:~/Documents/Postman$ export NO_PROXY=localhost,127.0.0.1
machine#dev:~/Documents/Postman$ ./Postman
This will make calls to localhost work.
I found a similar problem on Windows machines here
The problem mentioned as an issue here. You should just write a simple batch file like this:
set HTTP_PROXY=
set http_proxy=
set HTTPS_PROXY=
set https_proxy=
START %LOCALAPPDATA%\Postman\Update.exe --processStart "Postman.exe"
open a simple text file, save this as a ".bat" file, and just run it!
I also faced the same issue, but the trick was I implemented both the methods that were stated earlier in the stack.
First I turned off the postman proxy as shown in below image.
Click Settings -> Proxy
And then turned off the SSL certificate verification check button.
Click Settings -> General
And then tried to hit my local server and finally it worked.
While attempting to Get https://localhost:5001/WeatherForecast via PostMan while developing a basic .NET Core (3.1) Web API (on Ubuntu Linux)
I got the error:
Could not get any response There was an error connecting to
https://localhost:5001/WeatherForecast.
I didn't notice the actual solution in the things to try at first, but if you check the highlighted text in the image you will see it.
You can see that the option is turned on in PostMan by default:
I turned the SSL Certificate Verification off and tried again and it worked.
If you are under corporate proxy and you are deploying your webapplication in localhost then no need to set proxy configuration like
http://username:password#corporateProxyServer:ServerPort in postman (Global Proxy Configuration).
As the app is deployed in local machine just use the localhost configuration in setting -> Global Proxy Configuration as :
proxy server : 127.0.0.1
port : 8300 (this is the port where the web application is running )
My problem was that i was setting an invalid Header token and it gave me the error
Error: Header name must be a valid HTTP token ["Accept "]
Warning: This request did not get sent completely and might not have all the required system headers
Just check your Headers.
Adding another potential answer to this for people to check after they've tried the other ideas here.
I was able to solve my own problem by checking the Postman console (View -> Show Postman Console) and then examining the error from the request (in my case it was because I had a newline character on an auth token).
In my case, I had to precede the localhost with https://
These steps solved this issue after 1 whole day struggle:
1) HTTP_PROXY= proxy.company.com:port
HTTPS_PROXY=proxy.company.com:port
to user variables, not to System variables. Make sure the the case is all cap.
2) Updating newtwork driver, and turning on Windows Defender......Make sure you don't see no reds in here.
I was not able to make any calls from postman to docker container running Couchbase Server. Very frustrating. Turns out I had proxy setting configured to some aws instance which has been long deleted.
Goto setting and remove the proxy setting and it worked like a charm on localhost/127.0.0.1/mac laptop eno IP addr or 0.0.0.0
In my case, I was using django-tenants and had to add the domain for the tenant in etc/hosts to get it working on localhosts. My entry for 127.0.0.1 now looks like
127.0.0.1 localhost test.localhost
My problem was forgetting to select Environment. From the drop down where you see No Environment in the image, select the name of your environment.
Menuka Ishan's solution above saved my hours of pain! I left the Global Proxy Configuration switched ON and changed the Proxy Server to 127.0.0.1. Switched OFF the Use System Proxy. I already had the entry 127.0.0.1 localhost in my hosts file under the path C:\Windows\System32\drivers\etc.
If you have active proxy in your system then make sure Global Proxy Configuration and Use System Proxy are turned off. To do this go to Postman preferences > Proxy. You can also try sending a request in postman without typing localhost (e.g. :8080/send)
i think i also found a perfect fix.
First you turn on global proxy configurations, add your local machine Ip which is 127.0.0.1,then also add localhost in the bypass.
Also turn off SSL verification.
It worked for me
This worked for me, i dissable the parrameter host in the header.
HOST Disabled
If anyone is looking for a solution to WooCommerce local install, here are the steps to make this work:
Go to Wordpress Admin > WooCommerce > Settings > Advanced
Create new API key, give it a name
Copy the Consumer Key & Consumer Secret to
your text editor
Open Postman
Create new connection Set the URL for
testing (GET) : http://mylocalsite/wp-json/wc/v3/orders (change
"mylocalsite" to yours)
Click on Authorization tab
Now here is the main change: Although in WC Rest docs, it says to use the "Basic Auth" - IT WILL NOT WORK. Since usually your localhost is HTTP
and not HTTPS. So "Basic Auth" is not relevant in our case.
You will need to change the Authorization to OAuth 1.0
Set Consumer Key & Consumer Secret respectively as it shows in Woocommerce
Click "Send" - it should work now
If still you have problems, try one by one the following:
File > Settings > Turn off SSL Verification
File > Settings > Turn off "Automatically follow redirects"
I am running a WordPress on an Azure Web app connecting to a MySQL server on a different Windows server. When loading the mentioned page in Chrome, it shows 2 popups 403 & Forbidden. Checking the console throws this error - ecbcc.js:2 POST /wp-admin/admin-ajax.php 403 (Forbidden)
This works fine on FireFox & IE but not on Chrome. Any ideas why?
This is because of your cache. Minified version of JS is causing the issue in chrome browser. Check or purge the cache and check for the permissions applied to cached files as well.
I faced the same issue but it took a long time for me to fix it. Because my solution was not caused by common things like cache, .htaccess, files permissions, etc. I apply all the possible solutions as described here. When nothing worked for me, then I talked with my hosting provider and the issue was on their side. Actually, the server has black-listed my IP.
Below is the reply from the support of my hosting provider:
After checking it, it looks like the issue is caused by trigger
ModSecurity rules.
ModSecurity is an Apache module that works as a web application
firewall. It blocks known exploits and provides protection from a
range of attacks against web applications. However, sometimes,
mod_security may incorrectly determine that a certain request is
malicious, while it is actually legitimate. In such a situation, we
can whitelist the triggered mod_security rule on the server, so that
you can bypass the block.
In order to properly investigate, we need you to share your IP address
with us. You can copy it from here: https://ip.web-hosting.com/
Looking forward to your response.
This error can appear for more than one reason. Except for the accepted answer, if you are using a shared hosting solution as a server then it would be best to contact the support of the service. Also if you use Plesk or Cpanel you can check the server logs to see if there is any false positive rule that from mod_security that catches the error. Then you can find the error that could look something like that:
ModSecurity: Warning. Match of "test file" against "REQUEST_FILENAME" required. [file "/etc/httpd/conf/modsecurity.d/rules/custom/006_i360_4_custom.conf"] [line "264"] [id "77140992"]
You can apply the ID on your firewall exclusion list (if this is provided by your hosting service) and then the server will not block the request anymore.
IMPORTANT: If you are not sure what you are doing, ask your hosting provider for support. Experimenting on live servers/sites is not the best option and I would strongly recommend avoiding it.
I use docker as my local dev environment and use the dinghy-http-proxy which adds a new TLD .docker to map request to a nginx-proxy container.
My websites are typically reached through an URL like http://devel.domain.com.docker.
I want to use ngrok to develop locally while accessing remote webhooks.
I successfully launched ngrok with the command:
ngrok http -host-header=rewrite devel.domain.com.docker 80
I can access the login form of my web application through the address http://randomsubdomain.ngrok.io.
However, I can't log in because it looks like the cookie session can't be set.
Indeed, cookies sessions are tried to be set for the domain devel.domain.com.docker but as we use randomsubdomain.ngrok.io in the browser they are blocked for security reasons.
How can I bypass this problem? Am I missing something in my configuration? Is ngrok the right tool for what I want to achieve?
Asked directly to ngrok.io support and got this answer:
No, you're not missing anything, that's just an unfortunate side effect of rewriting the host header. Host header rewriting only works for some applications because of complications like this (and others that involve javascript and cross-origin, etc). If possible, it's always much better to reconfigure your website to accept the ngrok.io host header.
However, I found a solution by checking if the request contains in the header x-original-host the domain ngrok.io, and then I alter the session mechanism (in PHP session_set_cookie_params) to use the x-original-host domain instead.
As mperrin said you have to alter php cookie session mechanism.
Reading from session_set_cookie_params:
Set cookie parameters defined in the php.ini file.
The effect of this function only lasts for the duration of the script.
Thus, you need to call session_set_cookie_params() for every request
and before session_start() is called.
The most important argument is $domain and to make ngrok work equally decent you can also use before session_start() the command ini_set() (see ini_set): ini_set('session.cookie_domain', 'xxx.ngrok.io');
It also took me hours to resolve for my custom hosting php platform but I knew that my auth subsystem should work under a valid hostname apart from localhost so I focused in how the cookies are set from my code.
Such kind of php environment settings should be set early by any decent php framework and that was one of my primary goals when I started building it (in my case I only have to change the value in a json text file at the server).