Bug - Not A Bug Password Hash

r8631 or possible 8630.

I have two separate installations of KoLmafia. All of the files, including the jar, are in two separate directories. I run two characters from the first instance and launch it using a batch file. I run a different character from the other instance and launch it by double clicking on the jar file. (Windows 7 and the difference in launch techniques is probably not relevant).

I launched the first instance and set a character auto-adventuring in the Post War Frat house. I had, at some point before the auto-adventuring, opened a relay browser (Firefox 3.6.9) and done a few things with the inventory but nothing to do with chat. There were no mafia chat windows open either.

While that character was running, I launched the other instance. The character auto-logged in according to settings. I then fired up Ascend and watched. During this run this character did open the Orc Chasm and then adventure there. I never opened a relay browser for this character. When I was done burning those turns I switched my attention to the first character. The gCli and an adventure counter of zero both indicated that the first character had completed adventuring. However, after the completed message there were several instances of

Password hash mismatch
Path: "/mountains.php"

Click to expand...

I find this most interesting because a) the character had not attempted to adventure anywhere except the Post-War Frat house and b) I had not initiated any action - the character was idle.

While it is certainly possible that the attempt to access mountains was triggered as a side effect of something I wasn't aware of, I have to wonder if somehow the first instance of mafia, with an open relay browser, was somehow grabbing traffic intended for the other instance. That would also explain a few messages that suggested that the second character was running into unexpected situations. Alas, those messages scrolled by and were not captured in the session log so I don't know whether mafia or Ascend generated them.

Just more information that might possible relate to the problem.

Running almost always with the most recent Daily Build on Windows XP, with Firefox 3.6.10, I never noticed this sort of error. I regularly run two separate instances of Mafia (from two different folders), and I see that each uses a different port for the Relay Browser: http://127.0.0.1:60080 and http://127.0.0.1:60081. I guess this should prevent mixed signals?

Unless both accidentaly log into the same kol server (www#.kingdomofloathing.com)

N/A

Zentor said:

N/A

Click to expand...

Please, fellow Northern Virginian, what are you saying is "N/A"?

Password Hash Mismatch?

Mafia is looping the message


in my GCLI. It still seems to be running correctly but the looping message makes it hard for me to see the results of my actions in the GCLI. It began after I logged out and logged back in. I'm running r9403. I tried to log out and log back in a second time to see if that fixed the issue but it's still happening.

Perchance were you playing in the relay browser?
If chat in the relay browser is attempting to get messages through mafia still using the old hash, I could see this happening (unless mafia automatically intercepts and fixes the hash, though I'm not sure that it does).

Close and re-open the relay browser if this is the case.

bordemstirs said:

Perchance were you playing in the relay browser?
If chat in the relay browser is attempting to get messages through mafia still using the old hash, I could see this happening (unless mafia automatically intercepts and fixes the hash, though I'm not sure that it does).

Close and re-open the relay browser if this is the case.

Click to expand...

Thanks. That must have been the issue, it stopped as soon as I closed the relay browser.

I believe someone said that anytime your session times out and has to log in again, the password hash has changed. If you've kept the relay browser open, it will keep trying to use the old password hash there.

I just merged four bug reports together. It wasn't hard to find them. I only had to search for "password hash mismatch".

Bale said:

I just merged four bug reports together. It wasn't hard to find them. I only had to search for "password hash mismatch".

Click to expand...

I'm on so many different forums where the search function doesn't work at all or pulls up results only vaguely related to the search terms that it doesn't usually occur to me to try a forums search functions anymore, sorry.

Bale said:

I just merged four bug reports together. It wasn't hard to find them. I only had to search for "password hash mismatch".

Click to expand...

Perhaps mafia should say "password hash mismatch. restart the relay browser." or something to that effect.

Problem is that's not the only thing that can cause it. In rare circumstances, you might get a mismatch somehow else... I've done it while testing by accidentally saving the relay image on a page and having it load up during another session. Restarting the browser wouldn't have done a thing to fix it. It's better to have the message be always-right than to have it be usually-right.

So, I'm curious. I've been having problems with a script I'm writing and I have this hash mismatch in my debug log. Now, it so happens that the script in question does use the pwd hash in visit_url.. and I currently have it coded as "choice.php?pwd&whatever". Would it be better and maybe catch this error if i made sure it used my current hash by coding "pwd=my_hash()&whatever". Or will that not make a difference? I know this is marked as not-a-bug, but this behavior with having to log out the relay browser if you lag out is kinda new. In the past, we've been able to just keep going after mafia re-logins with the exception that we couldn't change characters and use the same relay window. Just curious. Thanks.

I think you should do:
If you only have "pwd" without any number after it, KoL will likely throw a hash mismatch error.

I thought that mafia automatically translated pwd to pwd=my_hash(). Is this not the case?

The string passed to visit_url() goes through GenericRequest.constructURLString(), but that doesn't add the hash. GenericRequest.getDataString() does, though, I don't know if that is called when the request is actually submitted.

Doing this in the gCLI
with debug logging on resulted in Mafia requesting this URL to KoL:
If I remember correctly, the debug log does show the hash when it is present, so I think that means Mafia didn't add it.

We would need to test with something that does require the pwd field though.

The debug log suppresses displaying the hash on POST requests. Simply using "&pwd" for visit_url requests should work for POST requests. You do a GET, you had better include it if you need it.

Ah... get/post differences. So I suppose it's good to add as a general rule and then you don't need to change when KoL requires alternate submissions.

It seems like I thought wrong