Access to XMLHttpRequest at 'http://localhost:8545/' from origin 'http://127.0.0.1:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
Web3js version: 0.20.7
Ran with below command:
geth --datadir ./peer2DataDir --rpc --rpcport 8545 --rpcaddr 127.0.0.1 --rpccorsdomain "http://127.0.0.1:8080" --networkid 1114 --port 30303 console 2>> myEth.log
The bug was introduced in 0.20.7 webjs. Make sure to use 0.20.6, works fine.
Related
I have a MongoDB instance on a Google compute engine running that I want to connect to from my Github action (On a windows runner if it makes a difference) to insert test and performance results.
Currently, I am trying to open an SSH tunnel with port forwarding and just test that the port is open.
Here is what my GIthub action step is:
- name: 'Create ssh tunnel'
if: (runner.os == 'Windows')
run: |
gcloud config set auth/impersonate_service_account *****#***.iam.gserviceaccount.com
gcloud compute config-ssh
$sshTunnelJob = Start-Job -Name SshTunnelJob -ScriptBlock { ssh -o "User=*****_iam_gserviceaccount_com" *****.us-east1-b.**** -vvv -fNT -L 27017:0.0.0.0:27017}
Get-Job
Receive-Job -Name SshTunnelJob | Format-List -Force -Expand CoreOnly
netstat -aon
Test-NetConnection localhost -port 27017
gcloud config unset auth/impersonate_service_account
gcloud compute config-ssh --remove
I expect this, Test-NetConnection localhost -port 27017, to succeed, but it fails. Forwarding port 80 is succeeding, though.
Here is the output:
WARNING: TCP connect to (::1 : 27017) failed
WARNING: TCP connect to (127.0.0.1 : 27017) failed
ComputerName: localhost
RemoteAddress: ::1
ResolvedAddresses: {::1, 127.0.0.1}
PingSucceeded: True
PingReplyDetails: System.Net.NetworkInformation.PingReply
TcpClientSocket:
TcpTestSucceeded: False
RemotePort: 27017
TraceRoute:
Detailed: False
InterfaceAlias: Loopback Pseudo-Interface 1
InterfaceIndex: 1
InterfaceDescription:
NetAdapter:
NetRoute: MSFT_NetRoute (InstanceID = "DD;9;?B55;55DD55;")
SourceAddress: ::1
NameResolutionSucceeded: True
BasicNameResolution: {Microsoft.DnsClient.Commands.DnsRecord_AAAA,Microsoft.DnsClient.Commands.DnsRecord_A}
LLMNRNetbiosRecords: {}
DNSOnlyRecords: {Microsoft.DnsClient.Commands.DnsRecord_A}
AllNameResolutionResults: {Microsoft.DnsClient.Commands.DnsRecord_AAAA,Microsoft.DnsClient.Commands.DnsRecord_A}
IsAdmin: True
NetworkIsolationContext: Loopback
MatchingIPsecRules:
What am I missing? Is GitHub limiting ports? I couldn't find any documentation on what ports are blocked or not.
Solution 1 :
The issue might be that the connection from client to server is blocked by a firewall. Can you Please check if the relevant GCP firewall setting is enabled for port 27017.
Also , Please check the target tags and update it accordingly if required . This will allow instances tagged with mongodb-instance to accept connections on port 27017.
Solution 2 :
As per the below output provided by you, it is observed that PingSucceeded was True. Whereas, the response returned as False for the PingSucceeded. In such cases, it is observed that the ICMP requests might be disabled on the remote server/device.
PingSucceeded: True
TcpTestSucceeded: False
As you are expecting Test-NetConnection localhost -port 27017 to succeed,please follow the below steps.
Open PowerShell in the Windows server and type the following command:
tnc <ip_address> -port <PortNumber>
If the device was having issues where it powered off or it got disconnected from the network, a response like below is expected.
PingSucceeded : False
TCPTestSucceeded : False
If the connection is healthy (i.e. MongoDb Server is able to successfully connect) then the following response in PowerShell is expected.
TcpTestSucceeded : True
The above response tells us specifically that the Port 27017 is open and the Test-NetConnection module was able to validate TCP handshake, so the port should be ready to establish a connection.
The above information is derived from the link which was drafted by Rodrigo Restrepo
I noticed that with a node on my AWS instance and geth node on my laptop, my AWS node can add my laptop as a peer, but my laptop cannot add my AWS instance.
Both nodes use a similar geth command line to the following:
geth --identity "node2" --rpc --rpcport "8000" --rpccorsdomain "*" --datadir "./" --port "30303" --rpcapi "db,eth,net,web3" --networkid 1432 --nat "any" console --nodiscover
Would anyone know the cause of this behavior?
I made Genesis block and turned on with geth
like this
geth --identity "PrivateNetwork" --datadir "/Users/username/dev/ethereum/data" --port "30303" --rpc --rpcaddr 0.0.0.0 --rpcport "8123" --rpccorsdomain "*" --nodiscover --networkid 1900 --nat "any" --rpcapi "db,eth,net,web3,miner" console
and... checked with this command:
eth.accounts'&'eth.getBalance(eth.accounts[0])
It works, however I don't know how to connect with mist
I had tried /Applications/Mist.app/Contents/MacOS/Mist --rpc http://localhost:8123 but what I can see is only this error message below
Error starting up node and/or syncing Error: Couldn't start swarm process.
at Timeout.error [as _onTimeout] (/Applications/Mist.app/Contents/Resources/app.asar/node_modules/swarm-js/lib/swarm.js:451:23)
at ontimeout (timers.js:386:14)
at tryOnTimeout (timers.js:250:5)
at Timer.listOnTimeout (timers.js:214:5)"
I thought geth is CLI client and Mist is GUI client for ethereum net
I'm not sure even It is right
Do I need to turn on both of them? or turn on only one? please help me!
Make sure you dont use the same rpcport for both of the applications. Use a different port for each one.
I guess you given wrong ip address. So when you run the command you will find below on your gth console.
INFO [01-31|10:32:06] IPC endpoint opened:
/Users/divum/Desktop/local-network/geth.ipc INFO [01-31|10:32:06]
HTTP endpoint opened: http://127.0.0.1:8545
Now try with
/Applications/Mist.app/Contents/MacOS/Mist --rpc [HTTP_END_POINT_URL]
Replace HTTP_END_POINT_URL with your log http endpoint url.
I have at Fiware Lab a virtual machine deployed with Context Broker + Wilma Pep proxy. PEP is configured with https enabled at config.js config.https = { enabled =true...}
Executing the command below I can see "https" process related to the node.js pep process
[centos#orion ~]$ sudo netstat -t -l -p
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:https *:* LISTEN 1492/node
But when I try to execute the following curl command I get the following message
curl -v -i -X GET https://public-ip-at-fiware-lab:443/v2/entities -H "X-Auth-Token: auth-token-from-idm-keyrock"
curl: (35) Unknown SSL protocol error in connection to public-ip-at-fiware-lab:443
What is missing in the configuration of PEP?
How can I debug what is happening in fiware-lab machine?
How can I test the SSL with curl command?
Any tip is wellcome!
Many thanks in advance
Finally I created a new certificate for the machine and the curl command works.
I am trying to interface with ejabberdctl remotely so my nodeJS client can send commands to a remote jabber server, using the mod_restful plugin with the ejabberd REST API. I am able to send a request using postman to test, with admin user and password sent in the header of the POST requests. I have edited my ejabberd.yml to include:
api_permissions:
"API used from localhost allows all calls":
- who:
- ip: "127.0.0.1/8"
- what:
- "*"
commands_admin_access:
- allow:
- user: "admin#localhost"
commands:
- "*"
- create_room: "*"
- register: "*"
# Tokens are valid for a year as default:
auth_expire: 31536000
oauth_access: all
and my ejabberd.cfg config file includes:
{mod_restful, [
{api,
[
{["admin"], mod_restful_admin, [
{key, "secret"},
{allowed_commands, [register, unregister,create_room]}
]},
{["register"], mod_restful_register, [{key, "secret"}]}
]}
]}
I am accessing my admin api at /api/admin and for some reason all the commands i try are succesfully authenticating, but I continually receive the error as response in postman:
"command_unknown"
I must have just incorrectly configured something, but I'm really not sure what. Im a bit confused of the overlap of settings between the YML and CFG files.