Yep, most scripts rely only on the cookie.
Here is the real boggle. When you select Remember Me, a cookie is set with both the Find w3t_myid and the w3t_key. However, if you do not select Remember Me, a cookie is still set only the cookie only contains w3t_myid.
So this is how I figure the thing works. When you log in, if you choose Remember Me, you get a cookie that lets you get away with not loggin in the next time you visit. That cookie is persistant.
If you do not select Remember Me, you get a cookie that is not persistant and only has your user number.
If you arrive at the UBB site with a cookie that has both the w3t_myid and w3t_key, then it lets you in and might start tracking you via a server side method.
If you arrive at the UBB site without a cookie or with only the w3t_myid field, you are prompted for a username, password, and asked if you want to be remebered. Once you enter this information, one or the other cookie is set and the server side trackign method begins if you choose not to be remembered and probably starts even if you did say you wanted to be remembered.
Basicly, upon arrival at a UBB site there is some method to identify you as you (either a log in or a cookie with both fields). From there, a session ID is established. I am willing to bet it is stored in the W3T_Users table as U_SessionId (which is itself a MD5)
So then, someone logs in and the U_SessionID is filled with an MD5. Then when ever they do anything that requires it, their cookie (either one) is checked for the w3t_myid field. Once that field is retrieved, the U_SessionId is checked against SOMETHING.
There is my problem, there are SOOOOO many things that could be used to generate that session ID. The last thing I wrote that used a similiar system added up all of the envirnornmental variables (IP, OS, Browser, and bla bla) and then turned that into a session ID via MD5.
Ahhh, you see my boggle now. How exactly is that mystical number arrived at?
You are going to make me go do a word search on that field arent you?
