By hebhansen on

When changing permissions for anonymous,registered and administrator the changes are not saved.

In the beginning I only had this problem in permissions (the big overview of all roles). I could work around it by changing from roles > edit. This meant that I had to repeat the proces for as many roles I need to edit permissions !!

Lately I can not change from roles > edit anymore. In other words I can not allow anyone access to anything other than God(admin) that is granted all permissions by default.

It seems that once in a while Drupal grabs my changes and then a minute later it does not!

I have flushed everything there is to flush. Even my toilet. I have cron'ed and whatever.....

I concider this a critical issue and I heard from others about the same issue..

⋅ Categories: Drupal 6.x

Comments

hershel’s picture

hershel commented

> Critical bug in Drupal!!! - I can not grant permissions as admin??

Seems quite unlikely actually, given the fact that tens if not hundreds of thousands of sites have been in production for months if not years, including this one. If such a serious bug existed, it would have been found and fixed by now.

Regarding your issue, could you provide more information, such as what browser and OS do you use? What precise version of Drupal? What exactly happens? Sometimes it saves changes and sometimes not? Is there any pattern to this? Is anyone else accessing your site. What type of server houses the site?

hebhansen’s picture

hebhansen commented

I agree , however:
http://drupal.org/node/679784#new

and beyond that a friend of mine has the same as well. So obviously we are 3 by now.

My setup is

Chrome - Windows XP Pro - Drupal 6.15 and Übercart - PHP 5.2 - Apache server

My friend use Firefox windows drupal 6.15 php5.2 apache

Exact happen:
- In the beginning everything worked fine.
- After a while I could not change permission from admin > user man > permissions
- I mentioned this to my friend. He said he has the same, but can change from admin > user man > roles instead
- I tried that and it worked for a while
- During december it became sketchy, sometimes changes were accepted and sometimes not
- I got the feeling that I could change once while log'ed in and only once.
- Tried to log out and in again and this was not the pattern
- During the past month I have only been able to change permission 2-3 times. I probably tried 10-12 times during january
- Today I have not been able to change anything and by now I have a significant number of modules not activated for anyone.
- Today I tried both permissions interface and roles interface. Neither of them worked. and yes I remember to save my changes

Just tried again from Permissions. Not working!

Not sure what to tell. Came sneaking over time. I can not relate this to installation of a specific module.

mtsanford’s picture

mtsanford commented

What do you mean "not working"?

What happens when you click submit after making changes? Do you get a "The changes have been saved." message? Are the changes you made not there when you go to admin/user/permissions again? What permission are you trying to change? The more specific the better.

hebhansen’s picture

hebhansen commented

When saving permissions it stay on the same page (Permissions), I get a green box saying.

Permissions let you control what users can do on your site. Each user role (defined on the user roles page) has its own set of permissions. For example, you could give users classified as "Administrators" permission to "administer nodes" but deny this power to ordinary, "authenticated" users. You can use permissions to reveal new features to privileged users (those with subscriptions, for example). Permissions also allow trusted users to share the administrative burden of running a busy site.

I do not get a save message.

Logs where? What should I look for?

hebhansen’s picture

hebhansen commented

Its any changes to any module and any role

faq
recaptcha
uc_adresses
nodewords
panels
minipanels

its any module

The check marks are simply not registered

mtsanford’s picture

mtsanford commented

And have you checked you logs at admin/reports/dblog, and other system logs on your host?

hebhansen’s picture

hebhansen commented

I had this in recent log entries

Details

Type update
Date Monday, February 8, 2010 - 09:11
User admin
Location http://www.mysite.com/admin/user/permissions
Referrer http://www.mysite.com/
Message Attempted to fetch information about all available new releases and updates.
Severity notice
Hostname 94.191.237.188
Operations view

mtsanford’s picture

mtsanford commented

Is the "submit" button doing anything at all? Does the permissions page reload, with changes gone?

There is another thread about this. It appears other people have fixed the problem by disabling modules (one at a time) until the permissions work, and then re-enabling, so there may be some module that has a bug.

http://drupal.org/node/587112

hebhansen’s picture

hebhansen commented

Thanks - I will play around with modules and see.... Thanks

Just tried the disable button in the far left menu, below cron and update.. still not working

mtsanford’s picture

mtsanford commented

My bet is some module you have installed is causing the problem. I just looked at the code for the submission of the permissions form, and it will always generate a "The changes have been saved." message, so the submit function is not being called. Modules are able to alter forms before they are shown, so it's likely a module doing this incorrectly and causing your problem. It is very unlikely it is a problem in Drupal core.

If you do narrow down the problem, please post back so others can benefit.

hebhansen’s picture

hebhansen commented

Will do - thanks and probably not Ubercart core either.

hebhansen’s picture

hebhansen commented

Not solved yet. I did the following.

Disable pretty much all modules one by one except:

Core
Core Optional
CCK
Views
Ubercart

Save between each and check in Permissions whether I could change settings. When saving, the site does not confirm anything saved, and nothing is saved.

Wondering if I should go for the last modules and if there is a risk in doing so?

hershel’s picture

hershel commented

De-activating a module should be risk free. To uninstall a module will mean loss of data, however.

ryanc’s picture

ryanc commented

The bug still appears to exist in 6.16.

ryanc’s picture

ryanc commented

I am having this issue as well on Drupal 6.14. Very strange issue, hard to imagine what the meaningful difference is between the permissions page with all users and and one with only one user.

fails
or both

I'll try upgrading to 6.16 and see if that helps.

hebhansen’s picture

hebhansen commented

I still have this after 6.16 upgrade....

I am not able to change permissions neither from permissions or roles interface...

This is limiting big time for further expansion of my site...

hershel’s picture

hershel commented

Can you ask your host to examine the error logs and see if there are any errors?

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

I had this problem a year or so ago. I couldn't save permissions or changes to block order. It turned out to be the Suhosin PHP module my host had installed. Something to do with it not handling more than 64 in an array or something? Sorry this is vague and it may not be it but it's something to look at.

Michelle

hebhansen’s picture

hebhansen commented

Does any of this ring a bell - my settings:

suhosin.post.max_vars (0 til 10000): 200
suhosin.session.cryptua: Disabled
suhosin.request.max_vars (0 til 10000): 200
zlib.output_compression : Disabled
suhosin.session.encrypt: Disabled

I know that suhosin.session.cryptua will block Flash uploads. That's why this is disabled on all my sites

hebhansen’s picture

hebhansen commented

I tried to enable suhosin session cryptua which is the default setting. It does not change anything and I still cannot change permissions.

suhosin.post.max_value_length: (0 til 10000000): 65000

hebhansen’s picture

hebhansen commented

I tried:

suhosin.post.max_vars (0 til 10000): 1500
suhosin.session.cryptua: enabled
suhosin.request.max_vars (0 til 10000): 1500
zlib.output_compression : Disabled
suhosin.session.encrypt: Disabled

That did not change anything

hebhansen’s picture

hebhansen commented

Something with 64:

suhosin.request.max_varname_length

Type: Integer
Default: 64
Defines the maximum name length (excluding possible array indicies) of variables that may be registered through the COOKIE, the URL or through a POST request. This setting is also an upper limit for the variable origin specific configuration directives.

suhosin.request.max_array_index_length

Type: Integer
Default: 64
Defines the maximum length of array indices for variables registered through GET, POST or COOKIE. This setting is also an upper limit for the separate GET, POST, COOKIE configuration directives.

suhosin.post.max_name_length

Type: Integer
Default: 64
Defines the maximum length of variable names for variables registered through a POST request. For array variables this is the name in front of the indices.

suhosin.post.max_array_index_length

Type: Integer
Default: 64
Defines the maximum length of array indices for variables registered through a POST request.

suhosin.get.max_array_index_length

Type: Integer
Default: 64
Defines the maximum length of array indices for variables registered through the URL.

suhosin.get.max_name_length

Type: Integer
Default: 64
Defines the maximum length of variable names for variables registered through the URL. For array variables this is the name in front of the indices.

hebhansen’s picture

hebhansen commented

http://drupal.org/node/210233
http://drupal.org/node/228379#comment-769413
http://drupal.org/node/229906

are suggesting that:
suhosin.request.max_vars = 1000-2048
suhosin.post.max_vars = 1000-2048

I tried 2048 for both and the issue is not solved for me...

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

I just reported the problem to my host and he fixed it. Looking at the various posts, though, it looks like that should be a big enough number. Maybe the changes just aren't sticking? I don't know... This is out of my area of expertise and why I have a managed VPS :)

Michelle

jruberto’s picture

jruberto commented

I was having similar problem saving a block admin screen with lots and lots of blocks. No error, it just silently failed. Problem turned out to be suhosin.

I think the thing that causes the most confusion is that suhosin logs its alerts to syslog by default (in Debian anyway), and most web developers are used to only checking the apache log.

http://www.dynamiteheads.com/blog/jakub-suchy/drupal-security-using-suho... Found this article which provides a Drupal-friendly suhosin.ini file, suggesting 4096 as the value for the max_vars limits...

hebhansen’s picture

hebhansen commented

My Drupal is phisycillay installed in subdomain 1 and subdomain 2 is directed to 1 and the settings.php base domain is set to 2. Changing php.ini for 1 alone did not solve anything. Now I changed Suhosin variables for 2 as well. Value = 2048 and I can now save permissions.

All in all Suhosin is the cause for this problem as described above.

Thanks for helping out

SpiesInOrbit’s picture

SpiesInOrbit commented

I was experiencing blocks that would not move regions when saved. The error was also showing up in my apache logs as "ALERT - configured POST variable limit exceeded - dropped variable ...".

I adjusted the suhosin settings similar the site mentioned above with the "drupal friendly" settings. And it worked. I dug further and determined that it was the default "suhosin.request.max_vars" that was the hang up and needed to be higher than 200 default value established by suhosin.

hebhansen’s picture

hebhansen commented

Exactly Steve, Also my findings as per above :-)