GingerRobot

Did you try looking at the manual page for the function you're getting an error on? If you type the function after http://www.php.net/ then you'll get taken straight to the relevant page. E.g. http://www.php.net/strrpos If you look though there i'm sure you'll see where you're going wrong. Also, i would recommend you start programming with all errors turned on. Add this line: error_reporting(E_ALL); To the top of your script. You'll then easily be able to see the variables which are undefined (and probably just need extracting from the relevant superglobal array).

For anything like this, the manual is your best port of call. Read though the material linked to here and , in particular, the incompatible section. Aside from that, you might also need to look at register_globals. If you've only just got round to upgrading to php5, you might well still be using an old version of 4 with that option still turned on.

Ok, well take a look at this line: $pos = strrpos($email, "@"); At present, $email is undefined. When register_globals was turned on, it wasn't. Why? Because PHP was automatically extracting it from the $_GET array. You need to do the same manually. Prior to the line above, you need to insert a line: $email = $_GET['email']; You'll need to do the same for any other variables coming from your form too. Make sense?

I'm sorry, what do you mean? Are you trying to work out the actual date given something like "4 days ago"?

Your problem is to do with register_globals. In older versions of PHP 4, this was still turned on. It meant that all $_GET, $_POST etc variables were automatically extracted from their arrays and had local scope. It is/was a security issue, however. You should fix this by doing the extraction yourself. E.g.: $email = $_GET['emal']

Is it actually innuendo when it's that blatant?

First up, i'm just going to direct you to this page of a tutorial i wrote. It'll show you how to make sure those queries are being executed and how to debug them. I suggest you start by applying that. Edit: Second, i also note that, unless defined in those included files, the variables used in this query: $query = "SELECT balance FROM at_client_profile WHERE email = ('$e') AND password = ('$p')"; Are undefined. Did you mean to extract them from the $_SESSION array?

Those are all just individual images with some javascript rollover effects. If that's what you're after, you don't need to do any image creation yourself.

Yep. You should probably salt that password though - it's much more secure.

Just fyi: there's already a function to reverse a string - strrev

If you're looking to generate an image, it could be done with the gd library

Yeah, that's exactly what I was saying. Though, i'm not sure i'd be talking about something being 'only' 2128

Adding more qubits just means i repeat my argument Now, if we have a computer with infinite processing power... Any any case, you're right with the last statement so having a known list of potential inputs to generate a hash isn't decryption it's basically still a rainbow table.

Or rather, because they're hashing algorithms and, as such, are one-way. Well... I suppose quantum computers might be able (one day) to recreate all possible inputs of hashing function that result in given hash So 'there is no possible way as of yet' is pretty accurate Not really. Given that a hashing function could accept arbitrarily large input, you could always increase the size of your input to generate a new value that maps to the same hash.

Or rather, because they're hashing algorithms and, as such, are one-way.

Try this: $vpage2= call_user_func('fAVINPicture', 'pics/', 'bild2.jpg', 'This is a picure of a giraff', '', '', $WapVersion); echo $vpage2 //assuming your function does actually return a value? call_user_func() is a normal function. You need to call it in the normal way. If you place a function name inside quotes, it doesn't get called.

So is the problem that the number of spaces between the data isn't fixed, so it's difficult to explode? If so, you might care to try split - you can explode by a regular expression with that, so you don't need to know how many spaces there are.

By default, PHP is buffered. You can force the output to be flushed to the browser with flush, however. Unless you're doing some pretty intensive stuff or you call sleep you're not going to notice it though. Also, if you want to test it, you'll need to echo and flush some white space to the browser or something - a lot of browsers have their own buffering and require a certain amount of data before they'll display anything. Edit: For example: <?php echo str_repeat(' ',256); flush(); for($x=0;$x<5;$x++){ echo $x.'<br />'; flush(); sleep(1); } ?>

And who are we going to annoy with 448119192934294x10^34 jokes now? Anywho, take care and good luck.

It'd probably be much easier to use call_user_func rather than eval in this case.

So you're storing these functions in the database but they're never modified? There's no real security risk there. However, it is going to be inefficient - apart from anything else, you have to perform a query before you can execute the function. I don't understand why you thought storing the functions in a database rather than in your file would be better?

Your php has nothing to do with this. You should be concerned with the generated HTML output. Also, you should drop the font tag and use CSS - the font tag was depreciated quite a while ago.

You don't escape $username in this query: mysql_query("UPDATE employers SET lastlogin = '$ndate' WHERE username = '$username'"); That could potentially be a threat depending on your register script (basically, it would have to have allowed a 'bad' query to have been used as the username).

I'm not overly convinced on why you'd want to do this...but anyway. You'll need to make the request to the first page, storing the cookie that is set and extracting the image name. Of course, if the image name is always the same, you don't actually need to bother, though you do still need to make the request to the first page to have the cookie set. Show the user the image. Then make the second request, providing the cookie data you saved from the first one.