I agree after examining some code on another site. So I need something to read the DB and return the logged in member’s username to a var, then echo this?
No, that should already be coming back when you first call getMemberByUsername(). It’ll be in your $user array, like the password and id are. But not in an array called $row, as that doesn’t exist anywhere.
The function is strange, though, in that it returns an array of users when, in reality, you should only be getting one user back. In turn, that makes the rest of the code more complex-looking because you have to use things like $user[0]["member_password"] when you could be using $user['member_password']. It would be relatively easy to modify, but it doesn’t affect the specific issue you have here.
1 Like
Got it:
$_SESSION['node'] = $user[0]["member_name"];
and
<?php echo "{$_SESSION['node']}"; ?>
Thank you, and thanks to everyone else! You all were very polite and helpful. I’ll be sticking around for sure. 
If you want to just output a variable you can skip the quotations makrs and curly brackets, thats very redundant.
1 Like
Cool, thanks! 
I did notice a small issue. The session code to produce the var is run just after login, and works. But if someone uses “Remember Me” when logging in, closes the browser, then comes back later, they are automatically logged in via cookie and sent to the main page. But since they did not technically login via the login routine, it now will NOT display the echoed var. Maybe because when re-loading the browser, it creates a new session?
I played around with it, and I couldn’t figure out how to fix it… suggestions please?
I believe that sessions are lost when the browser is closed. It’s remembering that the user is logged in because you do that with cookies, not sessions.
1 Like
Yes, gotcha. Maybe I can add a small piece of code that pulls the logged in member’s name from the DB when they hit the main page?
You could. Or you could store that in a cookie, as well.
I’m not sure what’s considered “good practice” on that score, but I’m sure others will. My guess is as long as the cookies don’t get overwhelming, and you don’t store something daft like their unhashed password, it’s probably OK.
ETA - just make sure that you don’t presume that just because you’ve had something from a cookie that it’s necessarily valid. It’s not difficult, apparently, to edit cookies at the client end, so it’s important to validate things.
1 Like
You shouldn’t store anything security relevant in a cookie because the client can easily change that. So storing a user-ID can also lead to identity theft when a bad client just changes the cookie value to some other ID and you just log that in.
But there’s a technique called “signed cookies” (ad hoc i didn’t find find any definitive resource for that) that utilizes encryption and hashing on any data stored in a cookie with a secret stored on the server, so you can rely on the fact that these data was validated server-side previously.
1 Like
I wondered if that was something to do with the other values the OP is storing in cookies - random_password and random_selector, some kind of security mechanism.
1 Like
Yes, there is an encryption method that uses hashed data in the DB and compares it to what’s stored in the cookie for validation.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.