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.
Related
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.
In this post about sessions, they basically say a session is a way the server has to identify a client (in subsequent requests).
The process consist in giving the client a cookie, that's the id. The client sends a request, the server does something like Session[cookie] --> details.
Some NodeJS/Express servers can create a session on connection, and set the loggin to true after successful authentication. Following the previous paragraph, we could do Session[cookie].loggedIn==true, then allow something.
I can see this either persistent or expiring cookies in the browser "storage" in the console.
But where in the server, and where on my machine is stored this data? Would a persistent cookie persist not only browser shutdown but also PC restart?
In a Home page, i have a form login. in the view.index of the app "Home", after authenticate, i create the ssesion. And after, i call the app "Places" if the authenticate is okey,
request.session['user'] = username
request.session.set_expiry(900)
return HttpResponseRedirect('/places/')
in the settings of the project i configure the SESSION_SAVE_EVERY_REQUEST = True.
How can i send the session to all others pages of the project, and log out the user when the session is expired ?
HTTP is a request response protocol.
This means that the server has no way to to communicate to the client without the client initiating the conversation. So the only way to do something like this is native Django, is to have the client periodically check to see if the session is still ok.
One way to achieve this is with a background ajax call (perhaps using setInterval in javascript) which checks the session, and if it's not any good anymore (either by expiration or the user has been disabled etc) then redirect them back to the login page.
Another approaches could involve sending the expiry time to the client so that it only checks the session when it would have expired (though this wouldn't pick up on users being disabled) or having a websocket server which pushes this information to the client.
I am trying to implement simple slack bot. So I have configured hubot which will take inputs from slack and passing it to my webapp (django app) and it will take whatever the response from django-app and will reply to slack.
In this process I am trying to store session in django using request.session but that is not reflected in slack. If I am accessing the django-url in browser it is able to store sessions and getting proper response with session.
So does the problem lie with slack or my approach and is there a way to store sessions in hubot when requesting to django-app ??
I can not speak to the specific technologies you use (hubot, django), but I am using server sessions with my Slack apps all the time and can give you a general answer on how it works. Note that my Slack apps are build with PHP, but I think its safe to assume that the principles are the same.
Slack does not support sessions
In general Slack does not support sessions or context. Instead everything is request based. So if you want to have sessions to keep a functional context between requests you need to organize that by yourself in your Slack app.
Challenge for using server sessions with server requests
One challenge is that most server sessions are designed to work with a client that uses a browser. e.g. a PHP server session will store a cookie in the browser, so the server knows, which requests belong to the same session. This does obviously not work with Slack, since all Slack requests are coming from a server and and there is no browser involved.
Approach for using server sessions with Slack
But you can use severs session with Slack with these two tricks:
Manually set the session ID
Usually the ID of a session is chosen automatically by the server, but you can also set it manually. This allows you to tell the server to continue an existing session that was started with a previous request.
Include session ID in Slack control
The functional session of a user is tied together by the Slack controls he uses. (e.g. an interactive button). Its possible to include custom data in those controls (see this answer for details) and that allows you to include the current session ID in it.
Full approach
You include the ID of your current session in the Slack controls, that you create with your app (e.g. an interactive button). Once the user clicks a button Slack will send a request to your app, which will include the session ID. That allows your app to continue an already started server session.
I have this one question in mind that in login sessions does client have to maintain anything so that server uniquely identify client and in multiple client requests response to correct client. I don't understand this sessions and cookies. I asked many about this some say that its server job to maintain sessions and client just send normal request.
Yes, the client must keep track of something, called a session ID. Most commonly, it is a cookie. However, a less used approach is to rewrite all links to pass the session ID in the URL.
Example ID names are ASP.NET_SessionId and PHPSESSID.
Matthew's answer is correct.
It is the server's job to keep track of login sessions, and it's the client web browser's job to keep track of cookies. When you provide username & password on a site, a cookie is provided by the web server to your browser, which will automatically be provided along with subsequent requests to the web server. This cookie uniquely identifies a session which belongs to a particular user on the site (even the "guest" user). So, the server keeps track of all client sessions, and each client remembers its session cookie & provides it along with all its requests. It's a simple scheme. Using Firebug for example, you can see what the web requests look like when you log into a site. You might find that interesting to look at.
It is the server which will maintain the sessions. And it is the server responsibilty to allow session tracking happen. Clients need not bother about sending any information explicitly. As Cliens also sends Cookies saved on the client along with every request, server might use Cookies for sesssion tracking.
Note: Cookies are just one of the way to implement Session Tracking. It is also the best way
So server Cookies as one of the ways to handle session tracking.
It can also be done in other ways:
URL rewriting - the application/server should append the session id in all URL's/Links. When those are invoked from the client the session comes to the server along with the URL.
Hidden Form Fields - The forms may contain hidden input type with session id as field value. When the form is posted, the session id comes along with the form data.