Daniel0

I don't quite get what you mean. Are you trying to get them in another format? Check out DATE_FORMAT().

In the constructor you need to do $this->oursql = new sqlclass(); instead.

Have a table storing the sessions. In that table there should be a column storing the last activity. On each request update that column for the current user. Then just count the number of sessions where there has been activity within a set amount of minutes (e.g. 15 minutes).

MD5 hashes are always alphanumeric strings with a length of 32 characters (^[a-z0-9]{32}$).

No. Two reasons: 1) A session id is not secret. It's send to the user. 2) A session id changes. The salt must remain the same. Otherwise the password will not be usable in the next session.

Well, by the looks of drisate's signature, it seems like he is a developer of an open source project, so chances are he implemented the algorithm he posted above in that project. Finding out is just a matter of downloading the source.

That's really poor encryption. The idea is about string length. Longer strings take longer time to crack. Seeing as a brute-force searching algorithm would run at O(n!), if there is a fairly long salt at the front of the actual password in the hash, cracking the password within reasonable time would be impossible. When brute-forcing your string one would just do md5(md5($string)); instead of md5($string);.

It could be, but it could also be generated dynamically. You'll just have to ensure that it's always the same for the same password, otherwise you cannot compare it again when a user enters a password.

Yes; but my point is lets say the user creates a password 'password'. Programtically we salt 123_ onto the beginning of it and we get 123_password, then encrypt it, and end up with our 32 bit password that we store in the database. If someone tries to brute force it and they enter 'password' into the box when trying to log on as a user, we have to progmatically attach '123_' to the beginning of what they entered so that the encryption will match up. The only place i see a salt being useful is if the database has already been compromised, and the breacher can see the encrypted password. I don't think you understand salting. It's supposed to protect brute forcing if you have the hash. If you add, say a 30 char long salt to the beginning, then nobody will have enough computational power to brute force within their life span (as long as the salt remains secret). To protect your login form, just restrict the number of failed login attempts and block the account for a fixed amount of time. Then it'll take a long time to brute force through your login form as well.

You're supposed to keep the salt secret.

That's what debuggers do, so just use one of them. They'll allow you to set breakpoints in an application/script where execution will then pause and you can view the contents of the variables.

Well I would rather do some extra coding once to get a "RoR Feature" than having to read code that a is bit more cryptic. Like Daniel said, you know the language well, it's not cryptic. It is very similar to Python, if any one here has ever coded in that. http://xkcd.com/353/

Hmm... I'd probably just do: users: - user_id - *etc.* modules: - module_id - *etc.* permissions: - user_id - module_id - bits Then SELECT * FROM permissions WHERE user_id = *user_id*; Then have an array in this format: array( module_id => bits ); Then if the key of the current module doesn't exist then they're denied access, otherwise you'd use the set permissions.

PHP can do binary arithmetic, so you can just do like this instead: <?php define('PERM_READ', 1); define('PERM_WRITE', 2); define('PERM_MODIFY_OWN', 4); define('PERM_MODIFY_ALL', ; $danielPerms = PERM_READ | PERM_WRITE | PERM_MODIFY_OWN; if ($danielPerms & PERM_READ) { echo 'Daniel can read' . PHP_EOL; } if ($danielPerms & PERM_WRITE) { echo 'Daniel can write' . PHP_EOL; } if ($danielPerms & PERM_MODIFY_OWN) { echo 'Daniel can modify own' . PHP_EOL; } if ($danielPerms & PERM_WRITE_ALL) { echo 'Daniel can modify all' . PHP_EOL; } var_dump($danielPerms); $danielPerms = $danielPerms & ~PERM_WRITE; if ($danielPerms & PERM_WRITE) { echo 'Daniel can write' . PHP_EOL; } else { echo 'Daniel can no longer write' . PHP_EOL; } var_dump($danielPerms); ?> Output: Daniel can read Daniel can write Daniel can modify own int(7) Daniel can no longer write int(5) As you see, the decimal value doesn't grow very much so it's unlikely that you with this approach will exceed the limits of the size of an integer.

I'd probably go with something like sha-256: hash('sha256', $string);

How is it more cryptic? That's like saying Russian (or some other language) is cryptic just because you don't speak the language.

Try to echo $rank before the preg_replace() to see if it contains the correct value.

Try this: <?php $var = 'Highest Skill - 29 (#79852)'; $new_var = preg_replace('/\s\(#\d+\)$/', '', $var); echo $new_var; ?>

The reason is probably that it's waiting while you're uploading. Depending on your speed, uploading a 20 MB file might take a while.

Could you show the code?

lol.

[quote author=rhodesa link=topic=112560.msg856502#msg856502 date=1207236673] Post #1000! Who wants to celebrate with me? [/quote] Post #3500 :)

Try to set display_errors to on and error_reporting to E_ALL in php.ini.

@keeB: The docblock must be outside the function, not inside. You usually also put the description before the @whatever things (I'm not sure what they're called). It would look something like this: <?php /** * This function does a loop. * * @param integer $p1 bla bla * @param SomeClass $p2 */ function doLoop($p1, $p2) { } ?>

What errors are you getting? That might help us locate the problem. It's most likely just a configuration issue.