We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. Session

Is there a way to get the user session from the session id

Hi everyone, I'm using phalcon's Phalcon\Session\Adapter\Redis adapter to handle my user's sessions, and it's working perfectly. Now I need to add an api endpoint to my project. so I can't use the same adapter, because this api will be separated (ish) from the main application I wanted to store the user's session id on a table and recover it when the api received a request. My idea is: Once the user logs into the application, and performs a certain action I will open a websocket connection to the api and send the user's session id (from the main application), and on the api I wanna find that user based on the session id received, am I being clear enough? Is that even possible? I really don't wanna move away from redis just because of this.

Thanks



77.7k

I'd advise against storing application (user) logic info in sessions. It would result in a session context switch every time a different user makes a request, and that basically defeats the purpose.

We are storing traditional session info in database. When a client sends a request, it receives a PHPSESSID and we store that to the user in the database. When the client initializes the js app, it connects to the websocket and sends the PHPSESSID as the token auth. Then we also store the websocket session id to the corresponding user.

This way you have all the info you need in the database, and can access it both from web and websocket.

EDIT: By "websocket" i mean WAMP, we are using the crossbar.io router. That implementation has a cbtid as the websocket session id



1.3k
in reply to Lajos Bencz

This is incorrect. It doesn't switch session context just because another person made a request.

I'd advise against storing application (user) logic info in sessions. It would result in a session context switch every time a different user makes a request, and that basically defeats the purpose.

We are storing traditional session info in database. When a client sends a request, it receives a PHPSESSID and we store that to the user in the database. When the client initializes the js app, it connects to the websocket and sends the PHPSESSID as the token auth. Then we also store the websocket session id to the corresponding user.

This way you have all the info you need in the database, and can access it both from web and websocket.

EDIT: By "websocket" i mean WAMP, we are using the crossbar.io router. That implementation has a cbtid as the websocket session id



77.7k
in reply to DrJLT

Then why on earth would sessions be useful? Clearly we are talking about the lifecycle of a single http request, not parallel requests from different users.

This is incorrect. It doesn't switch session context just because another person made a request.

I'd advise against storing application (user) logic info in sessions. It would result in a session context switch every time a different user makes a request, and that basically defeats the purpose.

We are storing traditional session info in database. When a client sends a request, it receives a PHPSESSID and we store that to the user in the database. When the client initializes the js app, it connects to the websocket and sends the PHPSESSID as the token auth. Then we also store the websocket session id to the corresponding user.

This way you have all the info you need in the database, and can access it both from web and websocket.

EDIT: By "websocket" i mean WAMP, we are using the crossbar.io router. That implementation has a cbtid as the websocket session id