Hi,
I want to build a function, which connects to a database and grabs user roles for a person logging in, and want it to assign that some session variable like say $_SESSION['userrole'] = Therolefromdatababase; . Would a function be able to return that ?

Say i have function xyz($var1,$var2) {
....
....
..

return $_SESSION['userrole'] = Therolefromdatababase;


}

?? Is that feasible or do functions cannot return or pass session variables or assign session variables some value ? Wait now i think of it, i can get function to return some role and use

this ?

$_SESSION['userrole'] = xyz(var1,var2) ;

Would that work ?

$_SESSION is a superglobal - you can read or write it anywhere. Just remember the session_start() before you try to use it.

Sessions are global, so you can set a value for
$_SESSION['whatever']
inside any function, and then use it anywhere in your script.
Your function doesn't have to 'return' anything.
Also, you could set the session to the value returned from
a function. Either way is up to you.

O i see did not realize that sessions stay or are considered as global variables.
Now since we at that topic, can i create a function to spit out just a global variable ? or do global variables have to be assigned to first page that gets loaded or something ?

What i am trying to achieve is assign a user a role for the time they are logged in getting the role from database and not having to query database all the time for role. Which route should i take ? Sessions route or something faster and safer exists ?

You could just start from the manpage example (http://au.php.net/manual/en/function.session-start.php) and work from there. Page 1 is your login page - it checks username / password and sets $_SESSION['userrole']. Page 2 is your admin page - it checks $_SESSION['userrole'] is valid for what you're trying to do and if not, redirects to the login page. (Edit: and don't forget to exit after the redirect!)

You could just start from the manpage example (http://au.php.net/manual/en/function.session-start.php) and work from there. Page 1 is your login page - it checks username / password and sets $_SESSION['userrole']. Page 2 is your admin page - it checks $_SESSION['userrole'] is valid for what you're trying to do and if not, redirects to the login page. (Edit: and don't forget to exit after the redirect!)

So session is the best approach to go by ? And in terms of security, how can i achieve that, so that someone cannot steal a user role not specific to their id ? Or sessions in general are safe ?

Sessions in general are as safe as anything else. If you're not using ssl, session ids can be sniffed, but then so can passwords, and it's better to be constantly sending session ids than passwords.

You might want to turn off session.use_trans_sid to prevent the id's appearing in any logs, and to secure the data from others on the server you can set the session path to store files somewhere inside the user's own directory.

And as with anything else that lets a user stay logged in, be aware of the possibility of XSS attacks.

Technically, $_SESSION is a superglobal, not a global. In truth, all variables defined out of the scope of a function or class are globals, you just need the global keyword to access them in a function. This differs from other languages, where you would have to declare the variables to be global when they are instantiated. A superglobal, on the other hand, is always made available at any scope.

Regarding where to store authentication information, I agree with foobic that $_SESSION is probably the best route to go.

Now as far as functionalizing part of your login process, I generally opt to return a value than to set superglobals. I just feel it makes the function more reusable.

never send passwords for sessions. only during login.

rather, create rather long and complex session ids by incorporating random strings, random numbers, the user's ip at that moment, and unix timestamp. you can md5 parts of this string too. use these as session ids.

You mean like this?

Array
(
[PHPSESSID] => 8fbddc7a4b067cbc66daf81de6e3199f
)
This is the cookie that PHP automatically sends when you use $_SESSION. All of the data that goes in the $_SESSION variable is then stored on the server*, not passed back and forth between the client. You don't need to save the password and authenticate it with every page load, but setting $_SESSION['authenticated'] = true is enough security for most apps.

* Of course you can override PHP's default session handling (http://www.php.net/manual/en/function.session-set-save-handler.php), but that's not really relevant to this thread.

never send passwords for sessions. only during login.

rather, create rather long and complex session ids by incorporating random strings, random numbers, the user's ip at that moment, and unix timestamp. you can md5 parts of this string too. use these as session ids.

OT--creating unique strings--:

I used to use "time.$$" (unix timestamp "." pid) in my Perl CGI days for creating unique strings. (Not likely to get the same process id twice in the same second when each CGI app spawns a new process)

With PHP, however, you just have the pid of an apache process which will live on after serving your script...two accesses in the same second could very likely result in a duplicate string using my method above. Anyone have a good way for creating a guaranteed unique string in PHP?

now its this.

its not wise to send php generated session ids with cookies and expect it to be safe, because any person which has a php executable in their hands can generate random php session strings with a script and try to hijack your users' sessions by planting them into cookies.

you need to create a complex, obfuscated string of your own, and implant the user's ip and a timestamp in them, so that the string becomes customized according to ip and the time that person was logged in, therefore making the string harder to imitate. of course add random strings to that.

time.$$ isnt bad, but a timestamp is guessable. you can try to guess process ids too.

hence the reason to insert random strings and use the ip along with it.

of course that may mean you may have to end up writing your own session class, along with the database table to go with it. but still it would work well.

its not wise to send php generated session ids with cookies and expect it to be safe, because any person which has a php executable in their hands can generate random php session strings with a script and try to hijack your users' sessions by planting them into cookies.The people who can do that won't bother - they're too busy generating next week's Lotto numbers. :stickout:

now its this.

its not wise to send php generated session ids with cookies and expect it to be safe, because any person which has a php executable in their hands can generate random php session strings with a script and try to hijack your users' sessions by planting them into cookies.

you need to create a complex, obfuscated string of your own, and implant the user's ip and a timestamp in them, so that the string becomes customized according to ip and the time that person was logged in, therefore making the string harder to imitate. of course add random strings to that.

time.$$ isnt bad, but a timestamp is guessable. you can try to guess process ids too.

hence the reason to insert random strings and use the ip along with it.

of course that may mean you may have to end up writing your own session class, along with the database table to go with it. but still it would work well.

A simple way around this is to add a timestamp to your session that gets re-stamped with every page load, or automatically logs out/destroys the session after x minutes.

The odds of correctly guessing a generated PHP SessID within 10 minutes of a user's last page load are pretty astronomical....certainly secure enough for most applications.

A simple way around this is to add a timestamp to your session that gets re-stamped with every page load, or automatically logs out/destroys the session after x minutes.

The odds of correctly guessing a generated PHP SessID within 10 minutes of a user's last page load are pretty astronomical....certainly secure enough for most applications.

people are lazy. they dont want to have to log in every time they visit a site, nomatter how long the visit interval is.

you need to drop some permanent authentication on their pc that you can securely use to identify them if they didnt change the pc they are on.

people are lazy. they dont want to have to log in every time they visit a site, nomatter how long the visit interval is.

you need to drop some permanent authentication on their pc that you can securely use to identify them if they didnt change the pc they are on.

I guess that depends on the app's specs. I mostly write internal corporate apps, so we have a little more flexibility to place requirement on our users. Besides, those lazy people are the same ones who are clicking "Would you like to remember this password?" boxes on their home PCs, on their friends' PCs, on library PCs...etc.

Personally, if the APP is spec'ed to have a "Remember Login" feature, I would require a key that has to be authenticated against the user's IP at a minimum. I just don't feel a big urgency to build that feature into an app unless it's specifically requested.

People SHOULD be logging in to and out of sites when they visit them, and if laziness out-prioritizes your willingness to let someone hack your personal info, I don't cry myself to sleep when it happens. The way I see it, if I access my online banking on my iPhone, leave the browser open and then leave my phone in a prison exercise yard...well, I've got it coming :)