I'm having a hard time trying to understand how a user can send a message after login since there is no exchange of a session token or any other kind of token.
For example, in PHP after you login a user, a Session ID is created for him which is stored in a cookie, and then everytime he visits a page, that Session ID is retrieved from the cookie, identifying him.
How does this work with XMPP/ejabberd since no token is exchanged after authentication?
I found this:
Session Manager:
This module routes packets to local users. It searches for what user resource
packet must be sent via presence table. If this resource is connected to this
node, it is routed to C2S process, if it connected via another node, then the
packet is sent to session manager on that node.
... but I'm not sure it is related to my question and even if it is, I still don't get how does this relate to the login the user just made.
In XMPP, a TCP connection is kept open (often with TLS encryption). Every message sent over that connection is assumed to be from the user that has authenticated.
Session support given by the urn:ietf:params:xml:ns:xmpp-session namespace is deprecated and most servers do nothing in response to <session/>.
Related
The site (laravel 6) has a page where we connect to the socket server in node (self-written sockets are used).
Node is just an intermediary between the client and laravel. Therefore, node then sends a post request to laravel with client data.
laravel needs to determine what kind of user it is, if everything is correct, then get access to its session data (do something with them, this is already business logic) and return confirmation of successful connection of this client to node.
If laravel has not defined the user, then returns to node a refusal to connect this client.
The question is how, with such a bunch, to determine in laravel what kind of user wants to connect?
It is possible to pass the encrypted session id stored in the user's cookies from the client to node and forward it to laravel. And how to start this session in a standard way and work with it?
I am new to web application , I am learning cookies and session, I understand HTTP is stateless protocol to make it stateful we use cookies at client side and session at server side.
When user requests a webpage it sends all the cookies available for that
browser on the PC.
If any one of the cookie matches with server side database , the server
shows the data , else sends set cookie with a session iD(optional to send
create session and send the session ID).
a. If server sends set cookie the client sends cookie in all respective
requests with the session id , only if the domain name matches with the
server to which the client sent .
Now my doubt is suppose I am working on an e-commerce site. And the server sends the number of items added to the cart till the user is not logging out , now it can be done using cookie alone why do we need session at all?
Is there something I am not understanding ?
These are separate concepts:
Cookie - Browser sends this with every request automatically
Header - Part of a HTTP request, the browser will only send data here if instructed.
Access token - Contains secret which may be a JWT (and identify the user) or a random set of characters
Session - a token bound to a user + device that authenticates the user. If the user doesn't have an access token, they can use the session to get a new token.
You can see that Cookie/Header are the where and access token/session token are the what.
The user needs to authenticate in your service. That means you need to be able to identify the user. That may be done with a JWT, session token, IP address, a signature, etc... And that is separate from how this data is transmitted to the service from the user.
So when you say why do you I need session when the user has cookies, these are totally unrelated. The session id may be saved in a cookie, that's just one option.
Whether or not the session id in a cookie corresponds to actual data on the server side is another completely separate question. Should the session token be a encrypted (or signed) object, like a JWT which contains user identifying information, or should that data be saved in a server side DB, and only transmit a random-string identifier. Who knows?
The answer is going to be based on what's critical for your application. Generally speaking, session tracking on the server side is a legacy concept, and the new hotness (which is old now), is to make the sessionId a JWT saved a HTTP Only cookie for security. And then passed on every request.
Lot's of services have sessions and access token management baked in, and for a working example and more about tokens, check out any one of many knowledge bases.
Because:
There may be, and probably is, sensitive data in that session, e.g. the user's id, identifying who the user is. If you just stored the user's id in a cookie, the user could manipulate it and easily pose as anyone else. There are of course ways to mitigate that, but simply not allowing the user to futz with the cookie contents (because it's just a meaningless session id) is the simplest.
It allows the server to manage session state; e.g. if a user suspects somebody is logged in as them on another device, they can invalidate all other sessions ("log me out everywhere" functionality).
You may be storing a lot of data, and sending it back and forth in a cookie on every request can become rather wasteful.
You may want to associate something like a shopping basket with the user's account, not just the user's browser, so when they log in on another device their shopping cart is following them around.
Yes, there are also perfectly fine cases were storing information just in a cookie is fine and preferable, especially since that allows you to scale your server more easily to a cluster of servers without having to worry about where the session information is stored. It depends on what information exactly you are storing.
The usual pattern is
the cookie contains only a unique session identifier (but no useful information itself)
the session storage (server-side) contains the associated data for this session. This can be a) very big and b) hidden from the user/browser and c) trustworthy (because the user cannot just modify it in the browser)
It is preferred to use sessions because the actual values are hidden from the client, and you control when the data expires and becomes invalid. If it was all based on cookies, a user (or hacker) could manipulate their cookie data and then play requests to your site.
Background:
I am performing some tests on an application which has a login feature. Client logs-in in the server, server sends it an authentication token and a user id. Client uses token and user id in next requests to authenticate itself.
I'm not much familiar with how such login sessions work. I'm confused about 1 thing that I need to confirm.
Question:
The way app is working is that both token and user id are sent in HTTP requests to retrieve sensitive data from server, but in some requests just user id is sent to retrieve sensitive data.
The confusion is, server needs to know that it is talking to an authenticated client. Servers usually verify it with session id or session token. When my client app is sending just "user id" then why is server responding to it, and giving it sensitive data...
In some apps, I have seen that both session id and user id have same value(separate entities but with same values), so probably in my app "user id" represents "session id". But why would server send both session token and session id...So, my question is
Can servers send both session token and session id, or they must(or mostly) send just one of them?
My main question is above one, following is a secondary question:
Are "session ids" and "user ids" usually same or different? If these are different, then is user id some session variable or something unrelated to session such as id of user in server DB?
P.S.: I'm not sure if it is the right site for this question. Let me know if it needs to be moved to some other stack exchange site.
To answer the question asked:
You may be confused about the role a session id plays. Session IDs and tokens are the same thing. A session id/token allows the server to perform some sort of look up which will indicate "requests with this session token are being performed by this user". So you don't need to send both the user id and the session token.
A little more information that you may not have asked for:
Session tokens do have some security concerns around them. They must be reasonably unique and should only be communicated over https. Also, remember that it is easy for a client to modify their cookies. So if a user id and a session token are sent, if the application blindly accepts the user id token then it may be possible for a user to log in, obtain a session token, and then change their user ID to some unfortunate user they wish to impersonate.
Now, perhaps you're thinking about authentication tokens? Session tokens can be thought of as a subset of authentications. They are predicated upon the server have a secret the client does not have access to. There's a few ways to do that, either create a reasonably unique value and store it with some extra information or perform some encryption of a value which only the server can decrypt.
In my application I use web services to get required information. To actually use this services you have to login first, you get your token - encrypted password, afterwards this token is attached to SOAP requests to identify current user. The thing is, when you do not use service for 15 minutes, your token changes and when you are trying to obtain another bunch of information from the server it denies old token. As a result app do not get required information and throws a heap of errors.
How to send user (load Login.axm) to Login page when token has been changed?
Thank you, Shay Shmeltzer for your answer.
How I solved this problem:
1) First I read how does sessions work in my particular case. I used stateless session which means -
A new session is opened for an initial request and the session remains
open for subsequent requests. Relogin occurs automatically
(transparent to the user) if the session is closed. UsernameToken and
PasswordText must be included as SOAP headers in the initial request
to open a stateless session.
Stateless session management is the best method to use for high-load
Web service applications. Using Stateless mode, the application
provides the username and password only once, that is for the initial
request. A session is opened on the server and is dedicated for this
user.
In the response Siebel Business Applications return the SessionToken,
which is an encrypted string containing the information about
username, password, and timestamp. For subsequent requests the
application must use the SessionToken to reuse the session.
For security reasons SessionTokens are regenerated for each response.
The application must provide the last received SessionToken for the
next request.
The SessionToken-Siebel session map is maintained in the Siebel Web
Server Extension (SWSE); based on the SessionToken value SWSE sends
the request to the correct Siebel session (task).
Although the session is persistent, authentication happens for each
request (SWSE decrypts the UserName and Password from the
SessionToken).
the main problem was :
NOTE: Reconnecting or automatic logging in again will only happen if
the token has not timed out. If it times out, then the user must
manually log in again. Token timeout must be greater than or equal to
session timeout. For more information on session token timeout, see
Session and Session Token Timeout-Related Parameters.
in my case standard session token live time was 15 minutes.
That is why I included counter in my code and checked it before each request. If counter time > 15 minutes, I sent log in request to the server to get new session token. The reason, I did not change current page to log in page straight away after the counter exceeds 15 minutes is: place in code, where I check counter is already initiated by the bindings to get required value to render it, so if your token has expired you will get a heap of errors. That is why firstly I renew the session sending log in request, get active session token and put it into the last request which is requested by binding. After app renders page without any errors, it shows pop up message "Session has expired" and goes to log in page.
You can programmatically set the soap header being sent to your SOAP service from ADF Mobile - http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/amxwebservices.htm#CHDIBIIE
Looking at the OWASP Session Management Cheat Sheet, every time a session expires, must a user go through the same Pre-Auth --> Auth --> ... steps to make a new session?
For example, if a session expires and the web app requires authentication, will the user have to log back into the web app before getting a new session?
Sessions are maintained with cookies.
Http is a stateless protocol. Every request to server works in isolation. No request has any information about previous request.
Say a user named A logs in to the site. This site works with session and sets session data for a user. Internally the server creates some value and associates with a particular user. A value 12345 is computed and associated with user A. The server decides to give this value's name as sessionId. It sends sessionId in the cookie and this cookie will be stored on the user's browser. Next time the user A makes a request this cookie will be sent to server. Server reads for cookie sessionId, and finds it. Then it sees with what user is the value in this cookie i.e 12345 is associated. It finds that this value is associated with user A and so its the user A, who is making the request.
Say this cookie expires, can be for various reasons. Either user deletes the cookie on his end. Or after certain days, server cleans this association between user and the session. In that case server will not be able to know who is the user making the request. And hence the entire flow of login by user, seesion generation will have to take place.
So, yes, if a session expires and the web app requires authentication, user will have to login again
Yes, the user has to log in again. Also, it's important that a new session gets a new session id, as an attacker could have gained the session id. If you re-authenticate the same session id, the attacker would gain access as well. See session fixation attack.
Depending on the safety requirements, you might also have to implement a maximum time to life for every session. Usually an attacker would take over a session and try to keep it alive as long as possible. Expiring the session after a certain amount of time, even if it is active, is an effective way to ensure that attackers can only have access for limited time.