Login flow

login_flow.txt

User enters the app(tralala mode), he logs in, I must save the SESSID and the
expiry date in the DB, next time he visits me I must check if he comes with some
PHPSESSID cookies, if he does then I must check if that SESSID is in the DB, if 
it is it mustn't be expired, then the user is logged in again, but if that SESSID
is expired he must relog and you must read from line 1 again :D

On logout I just delete his SESSIDs from the DB and destroy the session.

Too many IFs in between. The first thing you could do, right after acquiring a connection to the DB, would be DELETE * FROM sessions where expiry_time < time(). If you then check for the user's SESSID and you don't find it, he's not logged in - no matter if it would have been an expired session or he has never logged in.

The side-effect: you keep the DB clean.

On logout I just delete his SESSIDs from the DB and destroy the session.

Yep that's ok. You still need to do the above at each request, as not all users press the logout button.

The first part of your comment is OK, I understood what you said, a little optimization trick.

You still need to do the above at each request, as not all users press the logout button.

I should delete his SESSID from the BD even if he doesn't presses "Log out"? (I think this doesn't cover all the use-cases)

Maybe I should do that only if that was a one-time session("remind me" was not checked on login), am I right?

With the "destroy the session at every request" part I agree.

When I say this:

You still need to do the above at each request, as not all users press the logout button.

I am referring to the query DELETE * ... - read: delete all sessions of all the users.

Maybe I should do that only if that was a one-time session("remind me" was not checked on login), am I right?

If you have a "remember me for 30 days" checkbox, then you can set the expiration time in the database accordingly upon login. The cleaning up process would remain unchanged.

"destroy the session at every request"

What I've said was implying "destroy ALL expired sessionS" - here is not about THE user, it's about MANY sessions of different users - you're really cleaning up the database. That's why I was saying on the mailing list that this way, in contrast to the cronjob one, is worse, because you have to clean up things which don't necessarily belong to the user who's actually triggering the request.