Entities in protected post passwords cause password mismatch

[dllh]

Repro:

1. Make a new post.
2. Give it a password with quotes or other entities in it (e.g. "here'quote")
3. With cookies cleared and as a non-admin user, supply the correct password to view the post.

Expected Result: Rainbows, unicorns, access to the secrets of life via the newly unlocked post.

Actual Result: The password doesn't match. This is because setcookie() automatically urlencodes the cookie value. So the sample password above winds up causing "here%27quote" to be compared to "here'quote" and there's a mismatch.

The attached patch corrects the issue. Another approach would be to limit input on the front end. The attached post is a simpler solution less constraining on the user.

[dllh]

Sorry, a clarification. The urlencoded value seems to be unencoded when brought back in for comparison, but with magic_quotes_gpc enabled, the quote is escaped. The patch checks for magic quotes and strips slashes if needed.

[dd32]

Rather late patch review..

get_magic_quotes_gpc() is not needed, as WordPress currently forcibly quotes them, in this case, $_COOKIE should always be stripslashed.

[dd32]

In [18712]:

Allow Apostrophes in Post Passwords. $_POST and $_COOKIE are always slashed. Fixes #17145