Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
1) D'oh! Shoulda thunk of that.
2) It didn't actually update anything in the owner record. All the fields appeared unchanged. It was not, AFAICT, corrupted.
3) Probably the only way to be certain would be to talk to port 25 directly and parse the answers. Painful.
4) I'm guessing SDES is just for maximum compatibility. I notice there's three other better encryptions available -- but only if they're compiled in.
4a) d'oh again. Yep, the salt is there. I'll change it in the config, to make life easier on the members.
5) Haven't seen it, but thanks for the warning.
Thanks!
Some notes:
1) The passwords are hashed, so even if your password is blank, there will still be an encrypted value in the password field of the memberlist. Blanking out the password field in the database will never work.
2) Yes, installing a board on top of itself will cause the owner account to be updated. It should not corrupt it, however. The installer may complain that there is a duplicate column, but it will not generate an error, per se.
3) Even if your php.ini file has e-mail enabled, mail may not be sent. This is due to the way PHP handles mail. The only thing the BBS can do is ask PHP if mail is enabled. It cannot tell if PHP actually sent an e-mail or not, which is really annoying. The way Wacintaki handles mail is it uses $result = @mail(...), and if $result is FALSE, then Wacintaki will complain that mail was not sent. If you wrote a script with a simple mail(...) call, then you may not receive an error message.
4) Important: Please note there is a security issue with standard DES, in that the salt is actually included in the hash. If your encrypted password is "Aso99bc1JN5YE", then the first two characters ("As") are the salt. To get your salt back to the way it was, just take a look at the first two letters of each hash in the database. I have an alternate encryption function in the board that strips the salt from the final hash, but of course I can't use it for member passwords for compatibility reasons.
5) There is a bug in older versions of Wacintaki and Wax Poteto that can cause the profile editor to blank out your password (by putting a space in the password field). This has only recently been fixed. For testing reasons, the installer will accept a blank password, but the normal registration screen and profile editor will not.
I'm trying to rebuild a board that suffered cataclysmic problems (long story, suffice to say the DB is all that remains, but I MAY be able to lay my hands on the pictures from a former user).
I'm rebuilding it on my own server, so I have complete control of the environment. (NOTE: FIXED SEE BELOW)
I have set up 1.3.13, and it didn't give any complaints about the database. It updated my 1.2 database and didn't throw any errors. The board can see all the users, and I can run a query from MYSQL on the userlist and nothing looks out of place. It will not allow me to log in, though. My suspicion is that something might have ended up out of synch because the installer tried to set up the owner as a user that already existed (me, in a previous incarnation), though it didn't throw an error that I can find. WP is accessing the database, because I can see all the information that is available to an unregistered user, such as pictitles, comments, other users, etc, so it's not a question of DB access.
I tried blanking the password on my owner username in the database, but it still would not allow me to log in (I restored the hash that was there after I tried that). I've tried creating a fake user, but it balks, claiming the Email can't be sent (and the fake user I'm setting up doesn't show up in the memberlist). Checking php.ini, the mail settings seem to be correct (sendmail is where php.ini expects it to be). I can telnet to port 25 and that works, so even though my sendmail isn't talking to the outside world, PHP shouldn't know that. (another PHP script I wrote for a local copy of my homepage happily sends the Email, even though Sendmail is probably suffering sensory deprivation fits in the background)
The flags in my username are GDMIUX (no "P") and I deleted the ninechime cookies from my list. So.... Something is fubar. Possibly the hash belongs to a different type? Based on the length of the hash, I'm guessing standard DES. Looks like from the code, you're not using automatic salt, so this may never work. I have no idea what the salt from the old board was.
HA! While I was composing this, I wrote a little script for generating a replacement password hash based on known salt (I think the old boards used automatic salt, because it's a number), and the hash I generated worked when subbed into the owner password.
Just put this script in a webpage by itself (I called it "crypt.php") and visit it. DELETE IT AFTERWARDS, because this is your password in clear text!
<?php
if (CRYPT_STD_DES == 1) {
echo 'Standard DES: ' . crypt('$yourpassword', '$yoursalt_from_config.php') . "\n";
}
?>
Copy the hash it generates and update the DB with it:
UPDATE op_oekaki SET usrpass='generated_hash' WHERE usrname="ownername";
(of course "op_oekaki" table would be different if you picked a different prefix)
After doing that, I can log in.
I suspect this means that all my users will have to request new passwords, because their old ones won't work, but I'll jump that shark when I get the page uploaded to an ISP. I could try to look through all your release notes and find out when you went from automatic to pre-selected salt, but I'm lazy. :-)
Hope this helps someone who's got an old board backup they're having trouble mounting.