There was a change in common.inc in this patch http://drupal.org/node/14591.
When a user gets a 403, then menu_set_active_item('#'); is called in drupal_acces_denied.
Because of this the value of $_GET['q'] is lost.
The action of login block's form is "/%23?destination=%23". (%23 = url_encode('#'))
So user cannot be redireced to the originally requested page after succesful login.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | destination_3.patch | 2.35 KB | chx |
| #5 | destination_2.patch | 2.36 KB | Steven |
| #4 | destination_1.patch | 1.45 KB | chx |
| #3 | simple_dest_fix.patch | 371 bytes | chx |
| #1 | destination_0.patch | 1.13 KB | Steven |
Comments
Comment #1
Steven commentedWell, here's a patch which restores the destination... but for some reason it doesn't work for me for the log-in block. Somewhere along the it seems to get lost.
FWIW, this bug was already there before that 404/403 patch, if you used a custom 404/403 handler. Now it happens for everyone.
Comment #2
Steven commentedTo clarify: the patch above restores the destination, and it correctly appears in the form action="..". But it is not being used by the form API.
Comment #3
chx commentedWhat about this?
Comment #4
chx commentedSteven drilled down to the core of this issue but run out of time, so I post instead
Comment #5
Steven commentedHere's a slightly improved patch. Instead of a non-existant path like "^" or "#", I just changed menu_set_active_item() to distinguish NULL from an empty string. This does not affect any usage of menu_set_active_item() in core. The benefit is that there is no longer a 404 in the watchdog after submitting a form on a 404/403 page.
Tested to work for both clean and non-clean URLs.
Comment #6
chx commentedisset is faster than is_null.
Comment #7
Steven commentedCommitted to HEAD.
Comment #8
(not verified) commented