premiso

Are you sure it is being set properly when the user logs in? Somewhere along the way $_SESSION['userid'] is not being set, or got corrupted some how. Also, are you calling session_start before the checkuserid script somewhere? (Just figured I would verify that as well). As both sets of code, I do not see that. Which would cause you an issue if it is not.

$body = ""; if (is_array($_SESSION[$sessionarray])) { foreach($_SESSION[$sessionarray] as $key => $val) { $body .= $val . PHP_EOL; } } if (mail($to, $subject, $body)) { echo("<p>success!</p>"); } else { echo("<p>Failed...</p>"); }

Look into substr. That will allow you to break the string and tell you if a certain char is a space or not.

Where are you setting the initial session variable? Are you sure it is being set properly, like it is not in an if statement that never gets ran? Also, where are you using $userid at, that it is not working. If it is inside of a function or class, it will not work because it has not been set as global.

When you pull the data out of the database and before you display it use nl2br to convert the new line character (\n) to a <br>.

That is hashing, not encrypting. I would avoid using the MySQL MD5 statement, as you are a bit more limited, with PHP you can salt the MD5 hash a bit better to make it more secure. Either way you go, do the same through out the whole script. If a user logins and you are verifying the login, use the MySQL MD5 or PHP MD5, do not mix and match as it will generate difference results. SHA1 is a bit stronger, but yea. I would avoid using the MySQL MD5 function, just because I see it as being a bit more limited in how you control it. Please be a bit more descriptive of what you want to know. When a user signs up you hash the password and store that in a database, when a user logins you hash the password they gave you for the user and check it against your database to verify they match. Pretty simple process.

$newline = "\n"; echo "This should be split up when source is viewed {$newline} ok!"; I also think that PHP has a built in constant as PHP_EOL

So your database is getting out of sync when they have logged out. You will need a cron job and a timestamp in the database that has the row "online" in it, such as "lastactivity" then the cron job would go through that table and if last activity is past x amount of time, change online = "no" for most online scripts it is a 5 minute interval. So if their last activity was 5 minutes, set online to no. You may want it at 30 minute intervals. Look into a CRON Job of Linux or Scheduled Task for windows to accomplish this. Also you will want to look into PHP CLI (command line interface).

Ok, so you are just contradicting yourself there. What is the real issue you are having/want solved? You want it, that when they close the browser and come back, if they have not logged out, their session information is still there? But after 30 minutes you want them to be auto logged off? If so, the information I provided to you on the lifetime being set to 1800 would allow for that. The lifetime being set to 0 means, once the browser is closed the session data is killed, removed gone poof! Setting that to 1800 would keep the session data for 30 minutes after no activity, despite if they closed the browser or not. If the 30 minutes is up, then they would have to re-login. Either I am missing what you want, or you do not know what you want...please elaborate on what you want to do exactly.

<?php ini_set("memory_limit", "32M"); // Take care of MySQL injection attacks if(!get_magic_quotes_gpc()) { addslashes_recurse($_GET); addslashes_recurse($_POST); addslashes_recurse($_REQUEST); }

ini_set ini_set("memory_limit", "32M"); As long as your host allows you to, that should work. Put it before the script processing starts.

Have you tested the variables, such as $img and verified that you are able to view that url? It could be as simple as the url is not found or a small typo or a missed directory.

Try increasing your memory_limit and see if it still causes an error. Chances are the script is not efficient and does not destroy any un-used images that came from the image function. If it left it in memory, it can quickly increase, so a 260KB image, that has been resized, saved and had a thumbnail saved, could potentially have 4-6 times that amount of memory used, depending on the code and if it was done right. Such as in the above, you have $imgsrc that is never set to null, thus it is staying in the memory eating it up. $imgdest = imagecreatetruecolor($w,$h); imagecopyresampled($imgdest, $imgsrc, 0, 0, 0, 0, $w, $h, $actw, $acth); $imgsrc = null; return imagejpeg($imgdest, $dstfile, $quality); Just small/simple items like that will help. If you do not want to re-work the code, increase the memory_limit for a bandaid. If you can have a max of 5000KB image, make the max memory_limit something like 32M or 64M as that should be plenty to handle that.

Unless you have modified something, all session data should be trashed at the close of the browser. It is default in PHP. You can modify this value in the php.ini or ini_set ini_set("session.cookie_lifetime", "1800"); // set cookie to expire in 30 minutes That should timeout your session cookie, thus killing the session in 30 minutes, or 1800 seconds. If the browser is closed, and re-opened your session will still be active unless the browser clears cookies. Set that value to 0 to have it anytime the browser is closed the session gets erased.

All that htmlentities does is convert characters that are interpreted by the HTML engine to their html entity code. So < gets converted to < and > gets converted to > so that it is not "interpreted" by the HTML engine as actual markup, but as straight text. If you are not using BBCode and just allow people to enter the URL like http://www.joy.com which gets converted, than you are fine. As javascript: should not be interpreted/activated by that. So if the user enters this: <a href="javascript:">test</a> Gets converted to: <a href="javscript:">test</a> Which will not get "processed" to where a user could click on a link to activate the script. If I am missing something there let me know. In the above mentioned "BBCode" post, without coding to thwart it this might be problematic: [url=javascript:]url[/url] When the BBCode gets parsed turns into <a href="javascript:">url</a> Which could be an exploit if clicked on, and chances are your BBCode is processed after the htmlentites called, as that is sort of the point to having BBCode, to allow users to "safely" enter links images etc, without opening up the realm of what they can do with html fully. To answer you question, if you are not using BBCode, the htmlentities will protect you. If you are, you need to look into determining if Javascript was put into the url tag before parsing the BBCode and removing/replacing that entry if it was.

If you are not parsing BBCode, than that whole statement does not apply to you.

It is saying, if you use the bbcode url tag, you are potentially vunerable to xss exploits in the manner shown. To prevent this, when you convert the url bbcode to it's html, you run a check to see if it executes any javascript. If it does, simply remove the javascript call or html entities that url after it has been converted from bbcode. You should be able to check using regular expressions, preg_match to see if there are any offending items. And or use preg_replace to replace them. So if there is a url=javascript you replace that with url= Hope that helps.

I am not sure if cURL does the same as socket, but perhaps you want to look into that?

You would use GET data, you may want to look into mod_rewrite to do exactly what you want. But the idea: <?php $image = isset($_GET['image'])?$_GET['image']:null; if (stristr($image, ".jpg") !== false) { $file = 'http://www.website.com/something/' . $image; }else { $file = 'http://www.website.com/something/no-image.jpg'; } ?> <img src="<?php echo $file ?>" alt="something" width="600px" height="434px" /> Then calling: yoursite.com/wallpaper.php?image=image.jpg Would pullup image.jpg etc. That is a rough description, but hopefully gets you moving in the right direction. You may want to invoke a file_exists to make sure the image exists before displaying it as well.

Ok you are providing one lined information that does not help us, help you solve your problem. The scandir function can be coded (if you look at the user functions) to recursively traverse directories. Be specific on what you want, not just "I need this" then 5 posts later, "Oh and this is another part" then 10 posts later, "and I forgot about this". Write what the issue is out in full and state it exactly, or else we are just picking at straws here.

scandir should be right down your alley.

So online.php is showing up, it just is not showing up where you think it should? I do not know, it was hard to figure out what you were trying to say in your last statement.

Why not just use the username/password as the unique authenticate then when they are logged in, show them the companies they are authenticated for and allow them to choose that way? With like a drop down or something similar.

What version of IE are you testing this on? Just another random guess, have you tried removing the Cache portion as well?

The thing to check is make sure this $dsp_connected = $sc_contents[1]; is returning what you expect it to return. Also add quotes around your include parameter: include ('online.php'); But if it does not hit that if statement, then chances are your variables are not what you expect them to be. Do some debugging and find out why.