Topic: md5_hex w/UBB error

[LoonyPandora]

Hmm, I appear to have found out my problem

I have changed the default Name of my cookie from YaBB_Uname to Veg_Rev_Uname. However, for some reason, my board still generates the YaBB_Uname cookie at some point (I have yet to figure out where, there is no code that I can see to generate this file)

This is what is throwing Album.pl off. If I have Both Veg_Rev_Uname, and YaBB_Uname cookies in my browser, then album.pl gives me the md5_hex error, and no-one can login to upload photos. deleting the YaBB cookies solves this, all errors magically disappear, and everything works.

You have to delete the YaBB cookies though, deleting the Veg_Rev cookies doesn't do anything....

odd or what? the cookie generating problem is a problem with YaBB so I'll follow it up over there.

EDIT: I've figured the whole thing out. I have 2 YaBB boards installed on the same server, they are installed in different directories, they are completly seperate in every way, except they are on the same server.

The other YaBB board I have sets the cookies with YaBB_Uname, because I haven't changed the settings for it. album.pl obviously get's confused by having two cookies from the same site, for the same thing. in the config section, I have my YaBB members directory set so it points to my main board.

Deleting the cookies from my test board cures the problem completely. I'm not sure if you would classify that as a bug, or even if it's fixable, but now you know whats causing it, maybe you could put it in the ReadMe, or the FAQ or something

Thanks again for the wonderful support you offer, and the fantastic script you have aswell!

[Mike Bobbitt]

Great, glad you figured it out!

I'll see if I can figure out a solution here, maybe by tuning up the cookie handler...

Thanks!

[TurnsAllYear]

I too have been trying to figure this cookie business out, and have come across something which I think may help. I have three YaBB forums on my server. The "Reports" forum is the active public one and the first I installed. A second, the "Test" forum, I cloned from the "Reports" forum and use for testing. I also cloned a third, the "AlbumRegister" forum, and want to use it simply for allowing people to register to get pw and username for album.pl (I don't want registered users of the "Reports" forum to automatically have access to album.pl). I have album.pl set for auth=3, using the members db of the "AlbumRegister" forum

Here's what I found: if I have browser cookies from the "Reports" forum (ie. from being logged in there) and go to album.pl, I get the dreaded md5_hex error. If instead I have cookies from the "Test" forum or the the "AlbumRegister" forum, I do not get the error and can login to album.pl just fine, with usernames from the "AlbumRegister" members db.

The big difference in these three forums is in the cookie names: the "Reports" forum, which generates the md5_hex error, uses the default names in YaBB (ie "YaBBpassword" and "YaBBusername"), whereas for the other two forums ("Test" and "AlbumRegister") I had changed the cookie names via YaBB config.

So, why not change the cookie names in the error-generating  "Reports" forum away from the YaBB defaults? I tried that and the problem was solved. Ah, the thrill of success!

So, may be that album.pl could be changed with regard to cookies, but the problem can be solved on this end with a simple name change.

Interestingly, if I go to the YaBB support forums and login, I get cookies with the YaBB default names, but having those cookies in my browser does not generate the error when I go to login to album.pl. So the full problem seems to be having cookies with the YaBB default names from the same server or domain name as album.pl?

One cookie question: it looks like the two cookies which album.pl creates upon login are set to expire in 5 years. Is there a way to change this - somewhere in the album.pl file?

Charles

[Mike Bobbitt]

Hi Charles,

This is good info, it helps me figure out what's going on with this... Here are a couple of notes that may help clarify what's going on:

* Cookies are only sent for pages within the domain they're set for. So if one is set for perl.bobbitt.ca/cgi-bin, it will be sent with any HTTP requests for http://perl.bobbitt.ca/cgi-bin (and any sub-directories of cgi-bin) but not for perl.bobbitt.ca/album or any other directory. Cookies from a site are only ever sent back to that site, so YaBB support forum cookies will never show on your local server.
* album.pl reads through all cookies that are available (I.E. sent to it), and pulls out any likely usernames/passwords. So if several cookies are available, album.pl gets confused, and will overwrite the usernames/password it extracts from the cookies except for the last one it encounters.
* Password checking aborts once it finds a match, but when it doesn't find a match, it keeps looking, using all of the methods it can come up with (including some odd MD5 hashing methods).
* you can change the default cookie name through album.pl too. Check for these lines in album.pl:

Code: [Select]

my $YaBBusername="YaBBusername";
my $YaBBpassword="YaBBpassword";

and you can change them to match the cookie names on your forum, if you've changed those.


All of this together means that if you're using multiple cookies on the same site, album.pl may detect them all, but will only extract and use the username/password from one. If that one happens to be the wrong one, album.pl will check it using all the ways it knows, including some MD5 checks that may throw an error on your sustem.

Soooo... When there's no cookie to check, or a cookie with the correct username/password, everything's cool. But when there's a cookie present with an invalid username/password (for the album) it forces album.pl to run some checks that will throw an error if you're missing some MD5 packages.

Whew! I hope that makes sense, and I think I *finally* have a complete picture of what's going on. Now to fix it.

I'll have to think about the best approach here...