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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greggles’s picture

I 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.

Steve Dondley’s picture

Status: Active » Fixed

Neither of the problems above can be reproduced with latest version of CVS. Marking as fixed.

Steve Dondley’s picture

Status: Fixed » Active

Wrongly set to fixed. I see this is a 4.6.5 issue. Setting back to active.

Robin Monks’s picture

Version: 4.6.5 » 4.7.0-beta3
Assigned: Unassigned » Robin Monks
Priority: Critical » Normal
Status: Active » Needs review
FileSize
701 bytes

This 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

Robin Monks’s picture

I meant 4.7.0-beta3...sorry for rushing Dries ;)

Robin

Robin Monks’s picture

http://drupal.org/node/44867 has been marked as a duplicate of this bug.

rkerr’s picture

Patch applies cleanly. Seems straight forward enough.

Richard Archer’s picture

FileSize
2.1 KB

menu.inc states:

* The found callback function is called with any arguments specified
* in the "callback arguments" attribute of its menu item. The
* attribute must be an array.

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!

Crell’s picture

The 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. :-)

drumm’s picture

I agree with Crell, lets keep the API as is.

Dries’s picture

Status: Needs review » Fixed

I 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.

Anonymous’s picture

Status: Fixed » Closed (fixed)