For example if I go to http://www.example.com/?q=user/5/edit and if the user 5 doesn't exist the form will be empty. But if you press the delete button below, drupal still asks for confirmation and if you confirm then gone. The drupal site will no longer open.
It seems it is very critical. The exact instance that has happened to me is explained below:
1. A user submitted a request for account creation.
2. I didn't check the admin mail and I was just browsing the user administration area and I deleted the new user created.
3. Then I checked the admin mail and clicked the url for enabling the user (although I was knowing that user is fake and I have already deleted). Just like that I clicked the delete button in the empty form.
4. My drupal site stop working any more.
Comment | File | Size | Author |
---|---|---|---|
#8 | 42137.diff | 2.1 KB | Richard Archer |
#4 | no_error_on_bad_404.patch | 701 bytes | Robin Monks |
Comments
Comment #1
gregglesI did not test the behavior listed above, but got as far as the "delete/cancel" option and cancelled.
Another weird twist is that you can visit example.com/node/99999999999/edit and it will give you a node that can be edited and previewed but not submitted.
Comment #2
Steve Dondley CreditAttribution: Steve Dondley commentedNeither of the problems above can be reproduced with latest version of CVS. Marking as fixed.
Comment #3
Steve Dondley CreditAttribution: Steve Dondley commentedWrongly set to fixed. I see this is a 4.6.5 issue. Setting back to active.
Comment #4
Robin Monks CreditAttribution: Robin Monks commentedThis can't be reproduced on my install either (in 0.5B3). From the code, I'd say it's impossible now, as chacks are performed. That said, there is an array merge error that occurs if you try to run that command:
warning: array_merge() [function.array-merge]: Argument #1 is not an array in *\drupal\includes\menu.inc on line 357.
And I have created a patch to fix that.
This patch is only for 0.5b3
Robin
Comment #5
Robin Monks CreditAttribution: Robin Monks commentedI meant 4.7.0-beta3...sorry for rushing Dries ;)
Robin
Comment #6
Robin Monks CreditAttribution: Robin Monks commentedhttp://drupal.org/node/44867 has been marked as a duplicate of this bug.
Comment #7
rkerr CreditAttribution: rkerr commentedPatch applies cleanly. Seems straight forward enough.
Comment #8
Richard Archer CreditAttribution: Richard Archer commentedmenu.inc states:
So isn't there a deeper problem here... that
$menu['callbacks'][$path]['callback arguments']
sometimes contains a string rather than an array?The bug that triggered this issue would be in user.inc:
'callback arguments' => arg(1)
. There are a lot more of these errors scattered throughout contrib but this is the only instance in core.Perhaps a better option would be to fix the bug in user.module and add a check for callback arguments being a string in menu.inc. Here's a quick patch that does that.
Even better would be to post bugs against all the faulty contrib modules!
Comment #9
Crell CreditAttribution: Crell commentedThe bug in user.module should definitely be fixed, yes. +1 on that.
However, I don't know about the performance impact of the is_array() calls. If a module passes in a string rather than an array, they should get an error thrown back in their face until they fix it. Otherwise, we're altering the API to allow either a string or an array, which is a performance hit. So -1 on fixing module developers' bugs for them slowly. :-)
Comment #10
drummI agree with Crell, lets keep the API as is.
Comment #11
Dries CreditAttribution: Dries commentedI agree with the observations. Modules that incorrectly use APIs are buggy and should be fixed. I committed the user.module part of this patch. Great work. Thanks.
Comment #12
(not verified) CreditAttribution: commented