Some users are complaining that they cannot access buddylist/requests and are brought to an "Access denied." page. Not all users are getting this error though. This error only happens when a user has requested them and try to access the buddylist/requests page. If there are no requests, they can access it properly.

Possible problems:
-problems with the node_access table?
-problems with duplicate usernodes that have been created?

might not be exclusive to buddylist itself. Any direction or suggestions would be helpful.

Comments

nodestroy’s picture

nodestroy commented

hi,

is this error depending on the users roles? (have you set access restrictions to the used views?)

If I remember correctly, a missing usernode don´t throw an "Access denied." error, the view would be empty (or without the entries from users without usernode)

regards,
dominik

SteveK’s picture

SteveK commented

There aren't any restrictions and I have set access to manage buddylist for all user roles. It seems to only happen when specific users request to be a buddy of another user.

q #2: what about duplicate usernodes? would that return an error?

radianceinside’s picture

radianceinside commented

see also: http://drupal.org/node/244043

radianceinside’s picture

radianceinside commented

To avoid/circumvent this problem, we've created an own view and directed it to the path/url "/buddylist/requests" (This view is showind the buddylist's pending requests and could easily be created by using the views-api).

criz’s picture

criz
he/him
Location Vienna/Austria
commented

yes, that should be a possible workaround.

however, this seems to be a relevant issue...

levonai’s picture

levonai commented

Hint to source of issue?
I'm encountering the same issue (running on the Jan build of buddylist2) and have found that if I 'empty cache' it releases the access denied behavior.
A wild guess - it might be related to the fact that the menu callback for 'buddylist' is placed within the 'may_cache' section of hook_menu, so access is determined sometime in the past. Does it make any sense?

SteveK’s picture

SteveK commented

I'm trying the 'empty cache' fix. I'll let you know if it works. Also going to try and mod the code for the hook_menu on a dev test site.

SteveK’s picture

SteveK commented

emptying the cache works, but only temporarily. Still havent tried modifying hook_menu callback.

breakthematrix’s picture

breakthematrix commented

I have the same problem - it's been driving me batty!!! It only affects certain users, and only some of the time. Clearing the cache does not work for me. Affected users are using different browsers, different operating systems. I'm using 5.7 on apache/mysql. I don't have any special roles, they are all authenticated users.

Shelly

breakthematrix’s picture

breakthematrix commented

Oh - and occasionally, the same thing happens when users try to access their private messages.

nodestroy’s picture

nodestroy commented

@usernode: i don´t think, that _duplicate_ usernodes can cause this problem (i have no duplicate usernodes, and the probleme exists anyway)

@menustructure (maycache): if the views are empty, there is no access problem. -> menustructure should not be main matter

maybe we can exactly define in which situation the error accours:

* userA, userB -> authenticated users, no admins
* defaul installation of buddylist, usernode and views
* no changes in module code

i have a fresh drupal installation with:
buddy_api, buddylist_ui, token, usernode, views & workflow_ng

and can´t reproduce the problem. (i tried every combination of incomming/outgoing requests, and tried to access buddylist and request page without problems)

maybe there is a problem with another module

can you confirm this?

leonelsandokan’s picture

leonelsandokan commented

I have the same problem when accesing /buddylist. It sends an "access denied" error. I set Spanish as the site's default language. A temporary solution for the problem is go to user account and set language to English, save and then set it back to Spanish. It works temporarily but the error comes back after a while.

Some suggestions, please?

yngens’s picture

yngens commented

same problem here
for some of the users some occasional times

SteveK’s picture

SteveK commented

here is my module list:

abuse
advanced_forum
buddylist2
cck
comment_redirect
constant_contact
devel
faq
filter_default
guestbook
htmlcorrector
imagecache
imagefield
imce
invite
logintoboggan
nodewords
paging
panels
pathauto
poormanscron
premium
privatemsg
profile_csv
quicktabs
quote
similarterms
simplemenu
stockapi
tinymce
token
usernode
views
views_bookmark
vote_up_down
votingapi
workflow_ng
xmlsitemap

taxonomy_access was enabled before.. but was disabled. I cleared the node_access tables to see if that was causing it, but still persisted.

SteveK’s picture

SteveK commented

editing the hook_menu() in the buddylist_ui module:

  if (!$may_cache) { 
   ....

then clearing the cache with devel/cache/clear seemed to fix the problem for the moment. I'm going to try this out for a week and see if anymore users continue to get the error.

criz’s picture

criz
he/him
Location Vienna/Austria
commented

And is it solving the problem?

I think I have to test the module on a new drupal installation, maybe I can help to fix the bug...

Anybody an idea?

SteveK’s picture

SteveK commented

This has not solved the problem. Still receiving this error intermittently and seemingly randomly.

levonai’s picture

levonai commented

Actually for me it did seem to solve the problem. Just make sure you don't simply reverse the !may_cache 'if' since then all the original callbacks that were under the !may_cache (after the 'else') stop working. Once I placed all the menu items under !may_cache everything seems to work fine.

I think the original problem might be with the way $edit_access is evaluated in a cache situation, but I can't say I truely understand the drupal menu system to be able to debug/analyze it.

nodestroy’s picture

nodestroy commented

i added the change to the menu hook to version control

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/buddylist2/...

for me it solves the problem too, maybe you can test and report. if its really fixed, i could make a beta release and start developing for d6. would be a great step for the future of buddylist[2]

nodestroy’s picture

nodestroy commented

any feedback? did that solve the problem at your sites?

criz’s picture

criz
he/him
Location Vienna/Austria
commented

Tested it on my site and it's working now. At least at the moment... :)

SteveK’s picture

SteveK commented

so far so good, I must have still had something under the else condition.

Sam Dark’s picture

Sam Dark commented

Seems that it works. Please update 5.x-1.x-dev to include this patch ;)

nodestroy’s picture

nodestroy commented
Status: Active » Fixed
Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.