I have a django application that I want to deploy using daphne.
Django application supports both websockets and http requests. I've converted the django to support ASGI.
I'm starting the server using :
daphne <project_name>.asgi:application
The server is able to accept websocket connections but unable to handle the incoming HTTP requests (throws 404).
Where am I going wrong over here?
P.S.: I'm not using django channels.
I had forgotten to instantiate 'get_asgi_application' while creating the django application. Hence, it wasn't able to accept HTTP requests.
Related
I have a service (written in erlang) that accepts websocket connection from my django application. Django serves the page and the js script that makes the calls to the erlang service.
Now I want to go through the django server also for websocket connection and messaging. That is to use django as a proxy that forwards websocket connection and messages from the client to the Erlang service and sends back responses from the erlang service to the client. Optionally django should also check request authorization before forwarding them.
Is that possible?
I think I have some confusion in the understanding of websocket server and webserver.
So I followed the tutorial of django channels, where I created a little app that listens on a channel and returns some response.
At the same time, I can still serve webpages with normal view functions, so how does django do this magic so that it works without me modifying anything in the nginx server config?
The documentation mentions how this works:
It separates Django into two process types:
One that handles HTTP and WebSockets
One that runs views, websocket handlers and background tasks (consumers)
They communicate via a protocol called ASGI, which is similar to WSGI but runs over a network and allows for more protocol types. [...] probably Daphne
I am currently working on a web project in django and there is a requirement to ensure the safety of transmitting data over a network (passwords, usernames etc.).
I've read on owasp cheat sheet about authenication that for safety reasons all passwords should be sent from a client to a server over tsl protocol.
https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Transmit_Passwords_Only_Over_TLS_or_Other_Strong_Transport
Django framework sends these over http protocol. Is it possible to make django send it over tsl or work around it in another way?
When you run a Django application on the Internet, it's usually looking something like this:
[Django Application] <-> [uWSGI] <-> [nginx] <-> [web browser]
You can use different components, e.g. Gunicorn instead of uWSGI or Apache instead of nginx.
The thing is, you simply configure the webserver (Apache or nginx or whatever) with an SSL certificate and listen for https instead of http.
I think you're using Django runserver command for server your app over HTTP. It is absolutely not made for production and is a really HTTP (only) server for development.
For serve your app across SSL/TLS, you must use a frontend as described in henrikstroem's response
I'm developing an iOS app that requires realtime dual-way server/client messaging.
I'm trying to use WebSocket++ to develop a WebSocket server app on an AWS EC2. Have to use C++ because that's the only language I know on the server side.
The problem is I'm a fresh guy on server side development. I have 2 very basic questions:
1, Do I need have to setup an HTTP server like apache/nginx in order to get websocket running?
That is, can websocket app live independently alone?
2, I have now setup an nginx server in case it is a must have, is there any resource that I can refer to to make nginx & websocket work together well?
No, you don't need a Web server, a (reverse) Web proxy or anything to have your C++ WebSocket server talk to WebSocket clients.
Nginx (as HAproxy) supports reverse proxying WebSocket. This can make sense in certain situations, like you want to terminate TLS at the proxy and forward plain WebSocket to your backend server, or you want to load-balance incoming WebSocket connections to multiple backend nodes. However, as said, this isn't required.
No you don't, websocket and socket for an HTTP server are two diffent things.
HTTP server is for the HTTP protocol while there is not protocol defined for websocket, you have to define it yourself typically by the mean of sending/receiving Json message (a stream of character which each side (the server and the client) knows how to read/write).
The goal of websocket is to offer to javascript through HTML5 an easy, light and quick way to communicate through a socket, without websocket you have to do that with web services and in that case you need a http server.
With websocket you can create an html file leveraging html tag and javascript, javascript use client side of websocket to communicate with a C++/websocket server program, and you do not need even a web server, in this scenario you have a "desktop web app" ! (here web term is only because you use html tags)
Same question, same answer, no again ;-)
Good luck, and welcome in the wonderful world of asio !
I have followed this tutorial: http://www.stephendiehl.com/?p=309 describing how to run a gevent pywsgi server serving Django with socketio behind a nginx front-end.
As this tutorial says, Nginx doesn't support websocket unless using a tcp proxy module. This proxy module doesn't support the use of the same port for socketio and classic serving, from what I understood the configuration look like that:
nginx listen on port 80
nginx tcp proxy listen on port 7000
Everything is forwarded to port 8000
Problem: the resulting socketio request doesn't include the django cookie containing the session id so I have no information on the requesting user in my django view.
I guess it's caused by the fact that the request is made to another port (7000) causing the browser to identify the request as cross-domain ?
What would be the cleanest way to include the django cookie into the request ?
Most answers in this question seem to indicate that port doesn't matter.
Also checked and supposedly WebSockets is regarded as HTTP, so HTTPOnly cookies should still be sent.
SocketIO seems to be using a custom Session manager to track users. Maybe try and link that up?