The anonymous user account can be edited

I'll take care of this one :-)

CONFIRMED on WinXP/Xitami CVS

Robin

Here is the patch. It removes the /edit and /delete operation from user 0.

Tested to work on CVS HEAD.

Robin

The patch didn't apply on head. I also like my solution better. ;)

killes: your patch looks broken. Shouldn't $user->uid be arg(1)?

One of us is confused, but who?

I don't think that $user->uid has to be == arg(1). it is a global var.

Anyways, my patch still applies (chx had concerns earlier, but the patch was made correctly and seems to be OK). And it's been tested to work. I also like the fact that mine covers the entire user, and not just the edit portion.

Robin

With killes' patch I was still able to fill out the edit form at user/0/edit , user/0./edit or user/0.0/edit to create a new user.

+1 for Robin's patch, which needs to be converted from DOS to UNIX format.

I've tried both patches, both seem to apply, both work, with the only difference that Killes's still allows Administrator to edit anonymous account.

But both patches fail to protect custom profile fields (If you create custom profile fields, any user still can access categories of profile fields for user 0).

So I propose this one, which removes all operations for user 0.

I've always thought that the administrator should be able to edit uid == 0 (the anonymous user) and that ALL of drupal should use the username provided by the administrator in that record as the name of the anonymous user to display (with a default to t('anonymous')). Likewise for anything else about the anonymous user that might ever be displayed.

Handling of the anonymous user has been schizophrenic. I patched it once, but then development moved things around in the 'variable' usage of anonymous so much that my patch no longer applied and making it work again would have taken a large amount of work, so I never re-developed it. But it's still the right way to do it: http://drupal.org/node/5639

we do want admin to update anon account IMO. so of all these, killes' looks best to me. we do need to protect those custom profile fields though (if they are really unprotected)

I encountered this bug in HEAD and submitted by patch here: http://drupal.org/node/43818

I hesitated before submitting what might be a duplicate bug, but since this bug has version 4.6.1, I did not think it appropriate to submit a patch for 4.7 here.

this bug still applies to 4.6.5.

Issue queue cleaning: labelling this 4.6.5 issue as normal - this appears to have been fixed to an extent in 4.7. I haven't tested jreyero's "custom profile fields" issue in 4.7 though..

Thanks
-K

Just in case it gets missed.

I'm afraid to change the version field of this issue, for the same reason described by yogadex in comment #11. I can't understand why his issue was closed. This problem still happens in HEAD.

Should this be marked as 'by design'? :P ;)

See http://drupal.org/node/43818

This bug also concerns 4.6.6. This is a modification of yogadex original patch for 4.7.

This is the wrong solution. You want something like this: http://drupal.org/files/issues/user_no_edit_0.patch.1. Like that, you return 404s instead of 403s.

Following Dries advice here it is the patch.

Hello!? Someone wants to apply this patch? I'll give you a big hug!!!

Still an issue

This patch will make user/0/edit return drupal_not_found().

This problem also exists in other places, though - OpenIDs, Tracker, View Profile: Should any of these be shown for the anonymous user? With the new menu system in place, I'm not sure if (and how) this could be fixed in one central place, rather than having to put this line into all relevant menu callbacks below user/%user.

Make an extra menu item for "user/0/%action" perhaps?

Also, should it be backported to Drupal 5.x?

Sorry for the extra post, I forgot to set the flag back to CNR.

No longer applies, poor issue.

Form won't validate because there's no username there, and it throws a notice:

notice: Undefined index: name in drupal6/modules/user/user.module on line 1361. 
You must enter a username. 

I reckon 404 is the best option for this and agree it could be abstracted to something more general.

Fixed by adding the condition to user_edit_access().

Haha, it probably helps to read through previous issue comments before posting!

Actually, my patch makes sense, because user/0/view returns 403 as well.

After applying the patch #25, I can still access the user/0/edit page when I am logged off.

After applying the patch #25, I can still access the user/0/edit page when I am logged off.

user/0/edit worked before the patch for me, but now returns Access denied.

A cache problem maybe?

This needs further testing...

I also get access denied on user/0/edit with the patch, so RTBCing this.

Ok, I patched by hand, and missed the parenthesis. That was the problem.

but I think the patch need a reroll, the line numbers does not match..

Re-rolled.

Great, looks good IMHO, so committed.