I have created a WebSockets connection from my website to my home server running a python script listening on port 3000. I can connect to the server just fine as the server logs that a client has connected when I load my page. However each time I connect to the server, the server automatically fires my servers receivedMessage() function and prints out a bunch of garbage regarding the connection. The servers logs are below:
A new client has connected
Message Received: GET / HTTP/1.1
Host: [Insert host name and port here]
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: null
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Sec-WebSocket-Key: 3DUmKD70X9p19IpLPjS2jg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
The snippet of code to connect to the server is simple enough:
var theSocket = new WebSocket("ws://[insert host name]:3000");
theSocket.onopen = function() {
// Web Socket is connected, send data using send()
theSocket.send("blah");
alert("SENT");
};
Also the alert box never shows up when the above script is run. What is causing all the connection details to print and how do I get it to send a simple string and successfully pop up the alert box?
Its likely that your WebSocket is never transitioning from CONNECTING to OPEN and thus never calling your onopen function. You need to make sure your python script is going through the Web Socket Handshake on the server side.
Related
I have a socket.io server setup on an AWS EC2 instance. I am able to connect fine, as are most people, but I'm running into an issue with a couple of users where the HTTP protocol version is undefined. I have supplied two requests to my socket io server, one with an expected HTTP version, and one where it is undefined. It seems that otherwise the requests are the same, which leads me to believe that the HTTP version is the problem.
GET Request that is working fine (removed specific ip/website info)
GET /socket.io/?EIO=3&transport=polling&t=Nit_A4F HTTP/1.1
Host: {{My EC2 Host:Port}}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: {{My Website}}
Connection: keep-alive
Referer: {{My Website}}
GET Request that is failing (Note line 1, where the HTTP version is undefined, rather than HTTP/1.1)
GET /socket.io/?EIO=3&transport=polling&t=Nit_UGj undefined
Host: {{My EC2 Host:Port}}
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: {{My Website}}
Connection: keep-alive
Referer: {{My Website}}
Pragma: no-cache
Cache-Control: no-cache
There's a couple of questions in this problem, really. First, is the undefined HTTP protocol version a common or reasonable use case? If so, is there a way I can manually set the HTTP protocol version on the frontend (Angular), or set up CORS to handle the undefined HTTP protocol version on the backend?
If the undefined HTTP protocol version is not a reasonable use case, is there anything these users can do to fix it?
Here is my current socket.io setup on the backend with CORS:
const io = require('socket.io')(server, {
cors: {
origin: '*',
methods: ['GET', 'POST'],
transports: [ 'websocket', 'polling' ],
credentials: true,
}
});
I don't have much on my frontend besides just connecting to the correct url, but here it is just in case:
export class SocketIOService {
private socket: io.Socket;
constructor() {
this.socket = io(
environment.socketUrl
);
}
sendData(socketEvent: string, data: any) {
this.socket.emit(socketEvent, data);
}
getData(socketEvent: string) {
return new Observable(observer => {
this.socket.on(socketEvent, msg => {
console.log("handling event");
observer.next(msg);
});
});
}
}
Any help here would be appreciated.
For anyone looking for an answer as to why this specific problem occurs, I can't say I have an answer.
The solution that was applicable to me to solve my issue was to upgrade my frontend and backend to communicate through https instead of http.
My aim is to run my Quasar app to other devices connected to the Local Area Network. I managed to run them as expected although, when I was logging in to the website, I am having this error POST http://10.0.0.20:8080/MyComposer/?submitId=3 404 (Not Found) despite working
fine on my localhost before. Why is it not reading the Classes in my index.php at the backend folder properly?
P.S. I don't know if this could solve my problem but when I used phpinfo() to debug, I noticed that the REQUEST_METHOD there is GET instead of POST. Is it possible to swap them? I'll try whatever you guys give me.
Console
General
Request URL: http://10.0.0.20:8080/MyComposer/?submitId=3
Request Method: POST
Status Code: 404 Not Found
Remote Address: 10.0.0.20:8080
Referrer Policy: no-referrer-when-downgrade
Response Headers
Connection: keep-alive
Content-Length: 151
Content-Security-Policy: default-src 'none'
Content-Type: text/html; charset=utf-8
Date: Tue, 28 Jul 2020 12:18:12 GMT
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Powered-By: Express
Request Headers
Accept: application/json, text/plain,
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,es;q=0.8
Connection: keep-alive
Content-Length: 49
Content-Type: application/json
Host: 10.0.0.20:8080
Origin: http://10.0.0.20:8080
Referer: http://10.0.0.20:8080/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
Headers.php
<?php
header('Access-Control-Allow-Origin: http://10.0.0.20:8080/'); //OR EITHER http://10.0.0.20:8080/ OR .$_SERVER['HTTP_ORIGIN']
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Allow-Max-Age: 3600');
if (strtoupper($_SERVER['REQUEST_METHOD']) === 'OPTIONS') {
if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']))
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']))
header("Access-Control-Allow-Headers: {$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}");
exit(0);
}
store.js
actions: {
LOGIN (context, payload) {
return new Promise((resolve, reject) => {
axios
.post('/MyComposer/', payload, {
headers: { 'Content-Type': 'application/json' },
params: {
submitId: 3
}
})
index.php
<?php
require 'Classes/Headers.php';
require 'vendor/autoload.php';
echo 'Hello!';
phpinfo();
use Classes\SubjectClass;
use Classes\TestClass;
use Classes\AnswerClass;
use Classes\LoginClass;
use Classes\RegisterClass;
use Classes\TeacherClass;
use Classes\StudentClass;
use Classes\AccountClass;
use Classes\AccessClass;
use Classes\SchoolClass;
if ($_SERVER["REQUEST_METHOD"] == "POST") {
$addsubject = new SubjectClass();
$addsubject->addSubject();
$addtest = new TestClass();
$addtest->addTest();
$submitTest = new AnswerClass();
$submitTest->submitTest();
$submitLoginData = new LoginClass();
$submitLoginData->submitLoginData();
$addAccountData = new RegisterClass();
$addAccountData->addAccountData();
$addSchool = new SchoolClass();
$addSchool->addSchool();
}
The problem was caused not by a coding error but due to two webservers being installed on the affected system, a XAMPP installation running on the default port 80 and a Node.Js server running on port 8080.
To diagnose the problem we first copypasted the URL being used in the script into a browser window which gave the same 404 HTTP error. This excluded the option that the axios.post() method caused the behavior.
Next the basic HTTP port assignment was tested. Calling the address http://10.0.0.20 (user's IP inside the local network) gave the correct XAMPP homepage. When checking the httpd.conf and in it the Listen setting (which should have been Listen 8080) we saw the Apache was using the default HTTP port isntead. Changing it to 8080 (as was used in the script) and restarting Apache resulted in the server not starting with the error:
Problem detected! Port 8080 in use by "C:\Program
Files\nodejs\node.exe" with PID 3808! Apache WILL NOT start without
the configured ports free! You need to uninstall/disable/reconfigure
the blocking application or reconfigure Apache and the Control Panel
to listen on a different port.
It was now sure that messed up ports were the cause of the problem. Removing the :8080 from the scripts made sure the requests were sent to the right server.
Cannot deploy my angular 7 project in AWS Elastic Beanstalk, but I could deploy my express project, any idea?
This is the Request.
Request URL: http://mingzhi-event-search.us-east-2.elasticbeanstalk.com/favicon.ico
Request Method: GET
Status Code: 502 Bad Gateway
Remote Address: 18.223.167.56:80
Referrer Policy: no-referrer-when-downgrade
Connection: keep-alive
Content-Length: 575
Content-Type: text/html
Date: Fri, 16 Nov 2018 10:39:03 GMT
Server: nginx/1.12.1
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Host: mingzhi-event-search.us-east-2.elasticbeanstalk.com
Pragma: no-cache
Referer: http://mingzhi-event-search.us-east-2.elasticbeanstalk.com/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Angular is a front-end engine, not a server. If you wanna deploy an Angular application on AWS without a server, you should store the application in a Bucket and properly set the permissions.
Otherwise, you have to set up a server (e.g. a NodeJS application, but whatever) and deploy it using Elastic BeanStalk.
I have a ReactJS client running webpack-dev-server on localhost:3000. It connects to a Hapi API server on localhost:8080 and I'm trying to provide a basic cookie using hapi-auth-jwt2 (I've also tried hapi-auth-cookie with equal results).
I can see the response header provides a valid set-cookie header and everything looks okay, but all my browser tests ignore it and the cookie is never set (verified by checking document.cookie and using the browser tools like Chrome's Application tab). When I connect directly to the API server with Postman, it picks up the set-cookie header correctly and stores it so I think it's just some kind of domain/port/host configuration issue.
As a simple test, I tried deploying to our ec2 environment but that didn't help. The ec2 environment is similar, with one instance serving the client and another instance serving the API. I've also tried modifying my local hosts file to redirect a domain like 127.0.0.1 example.com and providing the domain=.example.com field in the cookie, but that also didn't help.
I think I'm just missing something basic but I don't know what it is. See below for response/request headers on login.
Request Headers
POST /login HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 47
Accept: application/json, text/plain, */*
Origin: http://localhost:3000
Authorization: undefined
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36
Content-Type: application/json
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Response Headers
HTTP/1.1 200 OK
authorization: <jwt token>
vary: origin,accept-encoding
access-control-allow-origin: http://localhost:3000
access-control-allow-credentials: true
access-control-expose-headers: WWW-Authenticate,Server-Authorization
content-type: application/json; charset=utf-8
set-cookie: cookie=token; Max-Age=604800; Expires=Wed, 16 May 2018 21:11:23 GMT; SameSite=Lax; Path=/
cache-control: no-cache
content-encoding: gzip
Date: Wed, 09 May 2018 21:11:23 GMT
Connection: keep-alive
Transfer-Encoding: chunked
http-proxy-middleware, which webpack-dev-server uses, has options for cookie domain/path rewrites.
You should see if those satisfy your needs. Otherwise you can also manually parse and reset cookies in the onProxyRes callback. Here is an example.
I was wondering how to respond to a javascript websocket handshake in Python 3, I can't seem to figure out how I should respond on the server side of things. I got this request from my client webpage:
GET / HTTP/1.1
Host: localhost:8080
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://www.w3schools.com
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Sec-WebSocket-Key: euv7CmNNT22p59HbD3X7ww==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
I can tell that I proably won't care about most of this, I just need to know what HTTP headers and such to send so that I can set this websocket up. Thanks!
Converted from Python2 code here: https://gist.github.com/jkp/3136208
Here is the server side Python3 code to verify client browser & return it an handshake confirmation:
MAGIC = b'258EAFA5-E914-47DA-95CA-C5AB0DC85B11' # Fix key for handshake on server side
class WebSocketsHandler(socketserver.StreamRequestHandler):
def handshake(self):
data = self.request.recv(1024).strip()
hsKey = hsUpgrade = b''
for header in data.split(b'\r\n'):
if header.startswith(b'Sec-WebSocket-Key'): hsKey = header.split(b':')[1].strip()
if header.startswith(b'Upgrade'): hsUpgrade = header.split(b':')[1].strip()
if hsUpgrade != b"websocket": return
digest = b64encode(bytes.fromhex(sha1(hsKey + MAGIC).hexdigest())).decode('utf-8')
response = ('HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\n'
'Connection: Upgrade\r\nSec-WebSocket-Accept: {}\r\n\r\n'.format(digest))
print('Handshaking...{}'.format(digest))
self.handshake_done = self.request.send(response.encode('utf8'))