Node.js

[astropos]

Perhaps a little toward OT but it's something that I'd like to get working.

Node.js is a serverside Javascript runtime.
It provides realtime communications via websockets. For my UserSpice projects, I'd like to be able to add realtime chat and/or other services via node.

I only want logged-in UserSpice users to have access to the Node services.

I'm going to start by sending a flag from USerSPice to say that the user is logged in.
I'll check this on the Node side and choose to allow access.
This is is a bit rough and easily spoofed.

It would be better to log-in to the Node server at the same time as USerSpice, using the same credentials against the same database.

Anyway, I'll just leave this here

[mudmin]

I like that idea. I've had a hard time modifying the login function (method) without breaking stuff, but I'm sure I'm just doing something wrong. It's not very complicated.

[brian]

I know at this point, table updates are somewhat undesired because it can make updates a little more complicated. But I've been racking my brain trying to figure out how to get the elapsed time since the user logs in, AFTER they have logged in. The Login routine modifies the last login seemingly during the login process and overwrites the last login period.

If you WERE going to be poking at the login script, then something I would REALLY like is to have a column in the table where the "last login" is copied (maybe called "last visit" or whatever, doesn't really matter) before the last login field gets updated. This way after a user has logged in, you can determine how many hours, days, whatever it has been since they were last on the side, and would allow custom content based on that interval.

[astropos]

Brian,

I did something similar in 3.3.

in login.php after auth and before the redirect you could put in two session vars:

$_SESSION['ll'] = $userdetails["last_sign_in_stamp"]; // whatever equivalent in 4.x
$_SESSION['lt'] = date("Y-m-d H:i");

Then you can compare those vars against themselves or other per-page datas.

This might not play well with remember-me :|

[brian]

Hmm, I think I need to be taken to school on PHP sessions. If it is that easy to add info so the session then that I could get all over. Definitely a temp variable rather than hitting the DB is fine with me.

[brian]

So I successfully created the session variable with the last login time before it was overwritten so that's pretty good. I guess that means that we can use that for, well, any session related data rather than hitting the database up each time. Thanks for that pointer, this should help quite a bit.