Yes, you can. You can keep the token in memory or LocalStorage and send it with every request. I'm using something like this with JSON-RPC where the token is the first argument to remote procedure. But as I've said you will need to have your own session mechanism because most default sessions use cookies. And for that you can use the database, of course, you can also use files or both (SQLite that is both file and database).
No, you're talking about a totally different things. Sessions are a concept proper to web servers, where some information related to user activity can be stored server side (in files or k/v stores) and are identified by a web server generated ID. That ID, by default navigates in cookies OR GET parameter (by default SESSION_ID=xxx). That's how sessions work. Some people try to use tokens as session storage in itself, but that in itself is a custom implementation. Using tokens to store session data is wrong. You can use tokens to store session id's, but that's fairly pointless. Tokens are used to store authentication (and authorization, stometimes) to authenticate requests (not to store session data). The issue I was talking about is server side data storage, the kind of that that you can't & shouldn't store client side.
Also, in memory storage is really bad, it's vulnerable to lots of attacks. LocalStorage is also bad (mostly it's also limited so you can't really store the kind of information sessions need) and vulnerable mostly to XSS. Secure cookies are best for storing tokens (though not as a means of communication, you write to cookie, then read to send separately while the server expects the token in dedicated headers and ignores the cookie data).
I think you don't u understand what I just wrote and keep changing the subject. First, you said that you can't use the database which is not true because you can use it for the session if you create your own mechanism.
Then you're contradicting yourself because first, you said that you can't have a session without cookies, and then next you said that you can use the GET parameter for the session_ID.
My comment only meant that you can create the session with a database and without cookies. You don't need to rely on whatever the platform gives you.
No man, what I'm talking about is the context of the OP: cookies vs sessions vs tokens, used as means of exchanging information that stores information about user activity. These terms were used under their proper definition (including session, as a server-provided ephemeral storage).
Yeah, sure, you can create your custom system, you can create your custom anything but what I was talking is what you can use to integrate within the sever provided framework (which already manages how clients are identified and whatnot). That's way beyond the topic of using what's provided. My point was merely to correct a statement in the OP which implied that databases are somehow part of the session mechanism (they're not). The session mechanism as per OP is what the server provides you. You could create your own, but that's not the same thing.
Also, the mere fact that something exists doesn't mean it's usable (session id in URL is as exposed as you can get) so I wouldn't consider as something that's in your toolbox.
Yes, you can. You can keep the token in memory or LocalStorage and send it with every request. I'm using something like this with JSON-RPC where the token is the first argument to remote procedure. But as I've said you will need to have your own session mechanism because most default sessions use cookies. And for that you can use the database, of course, you can also use files or both (SQLite that is both file and database).
No, you're talking about a totally different things. Sessions are a concept proper to web servers, where some information related to user activity can be stored server side (in files or k/v stores) and are identified by a web server generated ID. That ID, by default navigates in cookies OR GET parameter (by default SESSION_ID=xxx). That's how sessions work. Some people try to use tokens as session storage in itself, but that in itself is a custom implementation. Using tokens to store session data is wrong. You can use tokens to store session id's, but that's fairly pointless. Tokens are used to store authentication (and authorization, stometimes) to authenticate requests (not to store session data). The issue I was talking about is server side data storage, the kind of that that you can't & shouldn't store client side.
Also, in memory storage is really bad, it's vulnerable to lots of attacks. LocalStorage is also bad (mostly it's also limited so you can't really store the kind of information sessions need) and vulnerable mostly to XSS. Secure cookies are best for storing tokens (though not as a means of communication, you write to cookie, then read to send separately while the server expects the token in dedicated headers and ignores the cookie data).
I think you don't u understand what I just wrote and keep changing the subject. First, you said that you can't use the database which is not true because you can use it for the session if you create your own mechanism.
Then you're contradicting yourself because first, you said that you can't have a session without cookies, and then next you said that you can use the GET parameter for the session_ID.
My comment only meant that you can create the session with a database and without cookies. You don't need to rely on whatever the platform gives you.
No man, what I'm talking about is the context of the OP: cookies vs sessions vs tokens, used as means of exchanging information that stores information about user activity. These terms were used under their proper definition (including session, as a server-provided ephemeral storage).
Yeah, sure, you can create your custom system, you can create your custom anything but what I was talking is what you can use to integrate within the sever provided framework (which already manages how clients are identified and whatnot). That's way beyond the topic of using what's provided. My point was merely to correct a statement in the OP which implied that databases are somehow part of the session mechanism (they're not). The session mechanism as per OP is what the server provides you. You could create your own, but that's not the same thing.
Also, the mere fact that something exists doesn't mean it's usable (session id in URL is as exposed as you can get) so I wouldn't consider as something that's in your toolbox.
Andrei is correct.. Jakub seems to miss Andrei's point.