roopurt18

Well, that's a quick fix but allows for unintended use.  You could rename a .doc file to a .jpg and upload it like that, even though it's not a real jpg.

How are you determining the type of the file?  You can use the file extension from the name or from the $_FILES array, but that information is unreliable.

If you wanted to eliminate writing a cron job you could do something like this: Let's say a user logs in today at 3PM.  They browse the site until 3:15PM and close their browser [i]without[/i] clicking your logout link. Tomorrow the user attempts to log in and receives a message from the site: [i]Your account is currently logged in.  Logged in at <Yesterday @ 3PM>, last activity recorded at <Yesterday @ 3:15PM> If this is a mistake you can force your account off by answering your secret question below.  To prevent this from happening again, remember to use our Logout feature.[/i] Based off this information, if the user currently attempting to log in is legit, they can deduce if they just forgot to logout of the site or if an unauthorized user is on their account.  Further, it allows the legit user to force off an illegit user. Note that this only controls the login process.  There is [i]still[/i] nothing you can do, AFAIK, to prevent a legitimate user from, knowingly or unknowingly, transmitting their session ID to a malicious user [i]after[/i] they've logged in.

Using a DATETIME stamp allows only one login if you init the field to NULL and disallow anyone from logging in when that field is non-NULL.  The field will be non-NULL when the user first logs in and from their normal browsing.  Anyone else attempting to log in will encounter a non-NULL DATETIME field and your script can prevent them from logging in again.  You need to add a cron job to reset stagnant DATETIME fields to NULL so that a user who forgets to click a Logout link can log back in later. You're right, the session itself is not stored in a cookie or through the URL, I should have been more specific.  The session ID, however, is.  There is nothing you can do to prevent a legitimate user from logging in and then, knowingly or unknowingly, transmitting their current session ID to another illigitimate user. http://www.php.net/session_start "[i][b]session_start()[/b] creates a session or resumes the current one based on the current session id that's being passed via a request, such as GET, POST, or a cookie.[/i] I'm not saying using the session ID won't work.  What I [i]am[/i] saying is that it [i]doesn't[/i] garauntee only one login per user any more than a DATETIME column and that using a DATETIME column [i]is[/i] easier.

One thing you can do, instead of giving people direct links to files that have been uploaded is create a ViewUploadedFile.php script.  This script would take a parameter, possibly the ID of which file to display, modify the headers to contain the mime content of the file, and use fopen to pass directly the contents of the file. This can get complicated, but it lessens the likelihood of someone uploaded a script and then pointing their browser at it.

It looks to me like they uploaded a PHP script with malicious code and then visited the file with their browser. (EDIT) It also looks like they know something of your file structure, which would indicate they've seen text dumps of PHP scripts from your server (unlikely) or that they've seen the code you post on these forums (likely).

Add a DATETIME field, I'll call it curr_activity, to your users table and initialise it to NULL.  When someone logs in set the field to the time that they logged in.  Every time they view a page update the time in that field.  To allow only one login per account you simply do not let them log in if that value is non-NULL.  In order to prevent someone from being permanently logged out, have a cron scheduled to run every [i]x[/i] minutes and set all curr_activity columns older than [i]y[/i] minutes to NULL. (EDIT)  I could be wrong, but I don't believe adding the session ID to the DB is any more secure than a simple DATETIME field.  The session ID for the client is seen in the URL or in a cookie which can easily be given to another user, assuming two people are working together to accomplish something.  I don't know if there's any way to truly enforce a single login per user; the most you can do is make it annoying enough that most people would give up trying.  And that would probably come at a time investment that is more than it's worth.

If you look at the wotsit link I provided, you will get detailed information on out to strip the relevant information out of a .doc file.  However, if you're looking for quick and dirty, you could create a regexp that contains all the characters you want to keep, negate it, and replace everything in the negated class with an empty string.  Not as reliable but probably quicker than disecting the format.

I wrote up a little script to test this out myself. Here is the beginning of the raw contents of my doc file: [code]ÐÏࡱá>þÿ 
þÿÿÿ‹Œÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á!` ð¿X8bjbj\­\­ .^>Ç>ÇX0ÿÿÿÿÿÿ¤¼:¼:¼:¼:,è:dh
X;X;X;X;X;X;X;X;ƒƒƒƒƒƒ$j‘hÒ“|§ÓÇ
¼:%@HÒ0á‰„N”A N”eN”eX;Z²;@ÉAò;4&<­X;X;X;§§³AX;X;X;Ó<Ó<Ó<Ó<äø"Äø"ÿÿÿÿ
Pharaoh Information Systems To do Last Update: Thu. Nov 9, 2006 [/code] If I add the following to the function: [code] $output = addslashes(str_replace($search, $replace, $input));     echo "<pre>" . print_r($output, true) . "</pre>"; [/code] then the beginning of $output looks like: [code] ÐÏࡱá\0\0 [/code] So in my case the substr portion returns only: [code]ÐÏࡱá[/code] as my word document. However, there are many more sequences of \0\0 before the actual document begins.  Chances are red means to capture the last of those sequences and return that with the substr function.

By doc file I'm assuming you mean MS Word.  There could be a version problem with the code you have.  This might help you out some: http://www.wotsit.org/search.asp?s=text (EDIT) Looking again at the code you have again, it looks like that particular function is looking for a double null char as the sentinal where the text ends, not begins.

There is only one session per user.  You call session_start() at the top of every page where you intend to use the $_SESSION array.

In order to use MySQL's DATE_FORMAT with the asterisk, you'd do something like: [code] SELECT *, DATE_FORMAT(col, 'format') AS some_name FROM table WHERE 1 [/code] But as Thorpe said, it's better to name your columns.

Are you talking about starting a new row in an HTML table every [i]n[/i]th record?

I could be totally off-base here, but I believe ASP is a Microsoft technology.  So if your webhost isn't running a windows server you could be SOL. Again, I could be totally wrong.

So what happens if two users some how pick the same password?

Looks ok to me.  Why don't you try echo'ing the actual SQL statement. Also, why use $counter when it's identical to $i?

My methodology is to keep $_SESSION as empty as possible.  As Thorpe said, any data you need to display should be accessible from the database. Your users are probably entering a username and password to access the site and you should be validating the information from the database.  On successful validation, all you really need to set is a single $_SESSION variable: $_SESSION['User'] = $username; // The username they're using On every other page, you can easily checking if the user is logged in with: if(!isset($_SESSION['User']) || strlen($_SESSION['User']) == 0){  // User is not logged in  // This is how we can block non-logged in users from viewing a page } In the case of Thorpe's example with $_GET['User'], you can do this: if(isset($_GET['User']) && isset($_SESSION['User']) && !strcmp($_GET['User'], $_SESSION['User'])){  // Logged in, User param in URL is set, and they both match  // Now we can pull info from the DB for this user and display it } Hope that helps.

If page 2 is really employeeinformationmenu.php, I'm wondering why you're changing the content type to a jpeg [code]<?php session_start(); $_SESSION['empcode'] = $_POST['empcode']; $_SESSION['middle'] = $_POST['middle']; $_SESSION['firstname'] = $_POST['firstname']; $_SESSION['lastname'] = $_POST['lastname']; $_SESSION['leavehours'] = $_POST['leavehours']; $_SESSION['password'] = $_POST['password']; header('Content-Type: image/jpeg'); // ??? ?>[/code]

http://www.php.net/function.exec

You would have to order by both number of leads and broker_id, in that order.  Otherwise you run the risk of one broker being chosen twice in a row, which may or may not be desirable.

You can typically find the source of the error using a simple echo statement and if necessary block comments ( /* comment */ ); Try it!

When you assign a lead, just record it in a table that has: broker_id, lead_id, date_assigned When it's time to assign your next lead you can choose the person who has last received a lead with: [code]$sql = "SELECT broker_id FROM lead_assigns WHERE 1 ORDER BY date_assigned LIMIT 1";[/code] You will have to make sure that when adding rows to this table to insert if the broker doesn't already exist and to update if they do.  Otherwise it gets a little trickier.

I didn't look really hard, but nothing jumped out at me. Usually when I have a problem like this I just insert: [code]echo 'hi2u';[/code] at the last point that echo'ed.  Then I just cut -> paste and move that line down the page until it stops displaying.  Then you know where it blew up.

You use <?php and ?> to jump in and out of PHP mode.  If you're inside of the <?php and ?> "tags," the text is interpreted as PHP and run as PHP.  If you're outside the tags it's seen as plain old text, whether or not it's HTML. [code] <?php session_start(); ?> <html> <head><title>hi2u</title></head> <body> <?   // back inside php! YIPPEE!   echo "my 'hi2u' page!<br />"; ?> </body> </html> [/code]

Assuming there are no parse errors following what was in the OP, the: [code]<br><br>         <?     } [/code] looks fine to me.  It's the unescaped double quotes in the echo statement.