Cookie Vars and how to get them, etc.

[djr33]

Well.... i've got a forum on my site. this means that everyone has a username and password. I'm interested in coding a few more things, like, for example, a poll page, or whatever.
I can easily get the stuff from the mysql db and compare to a login they supply, but that's kinda a pain.
The forum already makes them logged in through cookies, so...

(I'm using IPB, but general answers will be fine... I can give more specific info if needed.)

How do I get their info from the cookies?

I also have the site working on two servers and I realize that cookies are related to the site that makes them; can I use cookies from one site on another?
I just want to GET the username and password they are logged in with, so it's fine if writing to a cookie is harder/doesn't work.


I haven't done a thing with cookies before, so start with the basics, please.

Thanks.

[mwinter]

The forum already makes them logged in through cookies, so...

How do I get their info from the cookies?

You don't. The only information that should actually be in the cookie is a session identifier. Storing anything more could lead to privacy or security issues, particularly if you start sending user names or passwords around.

The session identifier will provide a link between the user and their details within the system. How, exactly, depends on that system (and I've not used IPB).

I also have the site working on two servers and I realize that cookies are related to the site that makes them; can I use cookies from one site on another?

You may, but there are possible limitations. For example, if your servers are foo.example.com and bar.example.com, you can set the domain attribute for the cookies to .example.com, allowing them to be sent to both servers.

I just want to GET the username and password they are logged in with [...]

Getting the user name is one thing, but getting the password should be impossible; the password should be stored in a hashed form[1] so that only comparisons are possible (by hashing the password typed by the user in the same way).

Mike


[1] This storage mechanism makes sending password reminders impossible. The password would need to be reset, instead. An alternative is to encrypt the stored password, but that is less secure.

[djr33]

Thanks for the input.

As for passwords, yes, they are encrypted, specifcally with the md5 has thing. That, and the username is stored in their cookie. So... get that from the cookie and there ya go. Just match it up to the hash in the db and it's good.

I'm not too familiar with the session identifier, but that might help. Since I would be able to get the hash and username, though, that's probly easier.


As for different servers... ew. My host doesn't do what you showed above, so I have two seperate things: thebrb.com and thebrbforums.com.
so... totally different servers, not just subdomains. Thoughts?


And... still, how do I actually get these values?

[mwinter]

As for passwords, yes, they are encrypted, specifcally with the md5 has thing. That, and the username is stored in their cookie.

Hmm, that's rather dodgy, in my opinion. Hashes can be brute-forced, which could lead to compromised accounts (not that anyone's likely to attack you, but still).

As for different servers... ew. My host doesn't do what you showed above, so I have two seperate things: thebrb.com and thebrbforums.com.
so... totally different servers, not just subdomains. Thoughts?

The cookies won't be transferable. Simple as that. If the user can log in at thebrb.com and do things there, they'll have to log in again if they go to thebrbforums.com..

And... still, how do I actually get these values?

Use the $_COOKIE superglobal:

$username = null;

if (isset($_COOKIE['user'])) {
  $username = $_COOKIE['user'];
} 

Mike

[djr33]

Ok... so... to recap:

The forum software I'm using has issues. Eh, ok. Whatever. I can't figure out how to crack it. If someone is that dedicated, then they'll hack it, crash it all, and I'll upload a backup. That might be amusing, anyway.


There's no way to fake a cookie transferring? I suppose I could use a link that would send the values to a page on the other server, then add that as well. That might work. Hmm... I bet I could do a cookie for each using some trick with stuff... like making two cookies at the same time, but one on each server... somehow connecting to both... meh.
I mean... how does spyware do it? You get a cookie from an ad that's not on that server. Some are popups, but others aren't. What's the trick there?
Any ideas? 'cause this would be really nice.


$_COOKIE['thisisreallyeasy']?? Whoa, nice. That's it? You don't have to specify the server, I guess... fun.
I'll play with this then. Thanks.

[djr33]

To expand above... I was thinking.

If I wanted to make a new login page for my forum myself and have that relate to the other pages as well, but save two cookies, one from each server, what would be the best way to make this happen?

The cookies would be indentical. The servers would be fully accessable... just not connected, it seems.

I'm trying to figure some stuff out, but it all seems a bit annoying to the user... two redirects... or a popup loading bar thing, or whatever.... hmm... yeah.




Also, will setting global vars work easily enough? I haven't done any of that, so i'm not sure how that goes.
I mean...
$var = $_COOKIE['var'];
But... can I use:
$_COOKIE['var'] = $var; ?
Any restrictions there?

[Twey]

Sessions in PHP are very simple to implement.
PHP session reference

[djr33]

Good news-- tried playing with cookies and it's easy. Just worked out how to check if someone's logged onto my forum and that'll allow me to give them access (or not) to my new pages I could code...


Twey-- that's a lot of reading.... lots pretty easy, but from just skimming (busy at the moment), I didn't see much about WHY to use sessions.
What's the basic idea there?
A one sentence explanation is fine

[mwinter]

[...] I didn't see much about WHY to use sessions.
What's the basic idea there?

HTTP is stateless. Clients connect to a server, send a request, receive some sort of response, then disconnect[1]. As connections are only temporary, state cannot be associated with them, and other intrinsic data like the IP address doesn't guarantee uniqueness. So, in order to store data (possibly large amounts) between request/response sequences, to identify new and previously seen visitors, and to associate data with the latter, some other mechanism needs to be introduced. This is where sessions enter the fray.

When a visitor makes a request to a resource managed by sessions, they are assigned an identifier (the session identifier). If the visitor's client supports cookies, the identifier can be passed back and forth this way. If not, URLs for both links and forms can be modified to include the identifier. Once the session has been established, data can be added to it which will be stored on the server, usually in the filesystem, but databases and other storage systems are also possible.

When a visitor makes a request later on, provided that the session hasn't expired or ended by a specific action, the previously stored data can be examined again as and when necessary.

Mike


[1] That's grossly simplified, but summarises the overall operation.

[Twey]

It's also more secure, as I believe Mike mentioned earlier, as it doesn't involve storing the password on the user's computer (although the session ID can also be used to wreak havoc if obtained by a malicious party, it expires, and so isn't so much of a threat).