Bug - Not A Bug Multi-eating only eats one

[slyz]

With r12255, something is wrong with multi-eating:

[COLOR=olive]> eat 3 tomato[/COLOR]

Eating 3 tomato...
You     gain 1 Adventure
Finished eating 3 tomato.

Refreshing my inventory showed that 2 of the tomatoes hadn't been eaten.

The debug log doesn't really show anything interesting, but here it is.

I'm sorry I don't have more time to spend on Mafia

 

[Winterbay]

Aha, so that may have been why when I told Mafia to eat two Knob pasties it only ate one. From my session log:

use 1 milk of magnesium
You acquire an effect: Got Milk (duration: 20 Adventures)

eat 2 Knob pasty
You gain 6 Adventures
You gain 5 Muscleboundness
You gain 5 Wizardliness
You gain 5 Smarm
You lose 1 hit point
You gain 1 Fullness
You lose some of an effect: Got Milk

(and I had one fullness left after this as well)

 

[Veracity]

This is the failed URL:

http://www.kingdomofloathing.com/inv_eat.php?whichitem=246&ajax=1&quantity=3

Here is a URL from the "eat some" link in the relay browser:

http://www.kingdomofloathing.com/inv_eat.php?pwd&which=1&whichitem=2342&ajax=1&quantity=5&_=1372629061698

The one you submitted had no "pwd" field, for some reason.

 

[lostcalpolydude]

I can't make it fail right now. I tried using the Item Manager, and I tried the "eat" CLI command.

 

[Veracity]

You know, I added a line to UneffectRequest recently:

			this.addFormField( "pwd" );

because it didn't work without that field. I could have sworn we used to put on the pwd for, essentially, everything. Apparently, that changed some time.

I probably should have researched when that happened and, perhaps, reconsidered that change (whoever's it was), rather than just sticking in an addFormField like I did - and which it looks like inv_eat.php also needs - and who knows how many other places.

When did we stop putting a pwd into all requests?

Or, perhaps, what are the conditions in which we occasionally fail to do that?

 

[lostcalpolydude]

At some point I made a change to not put pwd into non-KoL requests.

 

[slyz]

I just re-logged my tomato-eatin' multi, and now it works. I can't check on my main because he's full, but I guess it was a transient problem on KoL's end.

 

[Veracity]

At some point I made a change to not put pwd into non-KoL requests.

	public String getHashField()
	{
		return ( !this.isExternalRequest ? "pwd" : null );
	}

and

		this.isExternalRequest = ( this.baseURLString.startsWith( "http://" ) || this.baseURLString.startsWith( "https://" ) );

That seems fine.

 

[Theraze]

Should isExternalRequest also check against the server website rather than just saying that any http or https request must be bad? From that it seems like anything that explicitly says whether it should be secure or insecure, whether actually on KoL or external, now has its pwd stripped now.

 

[Veracity]

We don't generate internal requests with explicit http: or https:.

I traced things in Eclipse and I see that the log not showing a "pwd" field for internal requests doesn't actually mean it didn't send one; when it creates the binary "data string" with all the fields for the request, it inserts a pwd, even if there wasn't a field already in the array for it. So, it's a logging issue - if it is an issue.

That makes me wonder why Uneffect stopped working for me until I stuck a "pwd" into the request. I notice that there is a handul of other internal requests that also explicitly stick in that field. Puzzling.

I think it is a KoL glitch.