I'm doing this -
Load single page application - an apollo client is initialised with a websocket and http link. This happens when the user is logged out, let's say.
The user then logs in without a page reload. The graphql response now contains the session cookie.
Problem - whilst subsequent http requests include the session cookie the websocket connection does not.
How do people solve this problem?
I'm guessing either make all communication with the server via websockets, or, create a new apollo client upon successful sign in and use this for subscriptions.
This is for a chat app. I'm using http and websockets at the moment.
Related
I have a Django backend that accepts WebSocket connections under a given url. The url takes a JWT token as parameter to authenticate users trying to use a certain websocket.
I'm trying to connect to a WebSocket from my SvelteKit frontend. The problem I'm having is that I can only access the Http-Only cookies containing my access & refresh key from within my +page.server.ts endpoint files. How would I go about authenticating the connection while also establishing a connection from the client side to access messages being sent via the WebSocket?
Currently I've been following this tutorial using a custom vite plugin as well as socket.io but it doesn't seem to be trying to achieve what I'm trying to work towards.
Any help, code samples and ideas on how to handle this problem would be very appreciated!
I connect several (anonymous, not logged in) clients via websocket / django-channels (routing.py, consumers.py). When a client reloads the page or reconnects, for whatever reason, he gets a new channel_name. Is there a nice way to identify the reconnecting client as the same client he was on first connect? Is there some kind of identifier?
If the client reloads in the same browser and you're using django's session mechanism, you will have a unique cookie (and therefore session) for each client. You have to save the session (in a view, not in your websocket) before it's useful, but that can be done on first page load.
I am using Dialogflow V1 with Django as the webhook target. The trouble I am having is that one of the Dialogflow servers somehow caches the cookie/sessionid and sends to the webhook every time, which is wrong.
In one of the webhook calls, my server creates a new user and logs in the user which in turn writes sessionid to the request cookie. Somehow the session/cookie will be cached by that particular DialogFlow server, and that server always sends the same sessionid/cookie to the webhook. With the sessionid, Django auto-login the request with the same user, which causes problems.
I tried the flowing ways to remove the cached cookie, but all failed
unset cookies
logout user: logout(request)
try to find a config in Dialogflow
Interestingly, only that particular server sends the wrong request, which causes our chat breaks intermittently.
Right now I have a Django-tornado-sockjs stack and want to be able to pass the session id from the site into a sockjs cnnection. What is the most secure way to pass the Django session id to my tornado backend? It sounds like people are recommending I store the session id in cookies and then send the data over when sockjs opens a connection. But isn't this less secure? It doesn't seem like Sockjs supports passing http-only cookies.
Any alternatives? At some point do I just have to accept I will have pass the encrypted session id though html or cookies and is there a real danger to this?
I'm far from a security expert but AFAIK requiring SSL for all auth requests is a baseline requirement to keep things secure if security is important.
We don't use session ids but instead generate an auth token on login, store it in redis which acts as the message queue between django and sockjs-tornado, and also pass it into the rendered page that establishes the sockjs connection via https. Then our sockjs-tornado process checks for the correct auth token in redis as part of the payload in a connection event.
We use haproxy to handle SSL uniformly across all the requests and dispatch to the appropriate backend which has been working great.
Found an issue Forms authentication Cookie not sharing between the requests to service.
Cookie '.ASPXAUTH'generated and sent to Browser from the Login service successfully, but not sending the Cookie to consequent requests for the same service.
Found When Calling service from Cloud app the request using HTTP 1.1 and for Response it is HTTP 1.0
More observations with the user of Fiddler and other tools:
Working fine for the following circumstances:
Running Service and Client website from local development system
Hosting Service and Client on same IIS (local and remote)
Accessing based on URLs, cookies transmitted properly
Not working for the following circumstances:
Hosting service and Client in different IIS servers.
Hosting Service in IIS (or Azure) and Client from local development system
Some more details:
Both requests made for the same service i.e. same domain, same protocal, same port nr, etc.
Updates at 20-12-2012 15:14:
As I said earlier Login functionality working on Ajax call without fail, Fiddler shows the Set-Cookie on Response, but Browser not reading the Cookie.
Tried to read document.cookies on "complete:" event of $.Ajax(), where I unable to read the cookie. means browser not getting or holding the cookie (where Fiddler shows on the Response of the same)
Regards,
Ramakrishna
Using the Forms Auth, have you performed some actions to take the ASP.NET Session out of process and out of server?
You cannot share the session between servers, so you have to either use SQL Session State provider and put session into SQL Azure, or use the Windows Azure Cache and provided Session State Provider to storage the session into a cache.
I'm sure you are good in using internet search engines, but here is a list of good articles to start with (taking the session out of process):
http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_buildingappswithcacheservice_topic3.aspx
http://msdn.microsoft.com/en-us/library/windowsazure/gg185668.aspx
http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx