Bug - Fixed Password hash logged in session log

[lostcalpolydude]

Occasionally, when choice adventure options are taken, the password hash isn't stripped before the URL is logged. I think this happens consistently when decorating the Crimbo Shrub, but there are inconsistent cases too. I've seen a log where it wasn't stripped when entering the underworld (choice 1023), though I don't seem to have any examples of that in my own logs.

 

[Veracity]

Looking at my session log:

use 1 box of old Crimbo decorations
Encounter: Shrubberatin'
Took choice 999/1: unknown
choice.php?whichchoice=999&pwd=c561f4c8859b7eb3384f53a3d00f6e95&option=1&topper=1&lights=1&garland=2&gift=3

Huh. It happened via a "inv_use.php" call - even though I did it from the Terrarium in the Relay Browser.

ChoiceManager.registerRequest is called by RequestLogger.registerRequest.
The only place which calls that is GenericRequest.execute, which calls it with the result of this.getURLString().

	public String getURLString()
	{
		return this.data.isEmpty() ?
			this.formURLString :
			this.formURLString + "?" + this.getDisplayDataString();
	}

	public String getFullURLString()
	{
		return this.data.isEmpty() ?
			this.formURLString :
			this.formURLString + "?" + this.getDataString();
	}

	public String getDisplayURLString()
	{
		return this.data.isEmpty() ?
			StringUtilities.singleStringReplace( this.formURLString, GenericRequest.passwordHashValue, "" ) :
			this.formURLString + "?" + this.getDisplayDataString();
	}

So:

getDisplayURLString strips out the password hash from either a GET or a POST request.
getFullURLString does not strip out the password hash from either.

getURLString strips out the password hash from POST requests but not GET requests. Why?

I think getURLString should have the code from getDisplayURLString - and strip out the password hash from both GET and POST - and the single place in the whole source tree which calls getDisplayURLString could then simply call getURLString.

 

[Veracity]

Yeah. Try revision 15546