watchdog gone crazy

Hi,

Looks like I found the issue.. I need to add a check for anonymous users before making that call. Your site's anonymous users don't have messages and can't have messages, so the ajax call is getting an access denied for those users.

It should affect any functionality and I'll try to have a fix in there for you by sometime next week.

Thanks for bringing this to my attention.

hey dave,

yeah, great module. works awesome. actually, the first time i got a PM, it scared me because it looked so good, i didn't think it came from Drupal.

But i'm seeing tons of those watchdog errors and lots of (i take it) spam traffic.

scott

I rolled a patch to fix this issue.

Since the callback url has the "read privatemsg" access, this patch only includes the JS if the user has that permission.

Also, I put the code in a hook_init() function.

BTW, this is a nice module. I have enjoyed it.

Edit: Sorry about #5, I wrote the comments, but they didn't get posted.

kswan: Awesome, thanks for the patch. I'll try to get this reviewed and committed in the next few days.. been watching it in Firebug and I knew that was the issue but hadn't had a chance to fix it yet. I think once this is committed I can role this out as a "Beta" release. Thanks again!

+  if (user_access('read privatemsg')) {

It may be better to use the privatemsg_user_access function here as it also checks to make sure that the user is logged in:

+  if (privatemsg_user_access('read privatemsg')) {

Excellent patch.

OK, this patch is now committed in HEAD, and soon the dev snapshot. Thanks!

Just wondering about http://drupal.org/cvs?commit=226070 where user_access() is now used instead of privatemsg_user_access() - was the latter causing any problems?

If not, I think it is a good idea to use the latter as then even if a site admin gives anonymous users permission to read private messages, that will still stop the access (because privatemsg module does not work with anonymous users).

nbz: I don't see privatemsg_user_access() in privatemsg 6.x-1.0-rc2. It is only in the -dev version. If a user doesn't have the -dev version they would get much worse errors than the watchdog warnings this patch was intending to fix.

oh, right. That would be a big problem.

Yes, that was the issue.. I wasn't running the dev version and got fatal errors when trying to use that function, so quickly reverted. I'm also not quite sure why an anonymous user should have the ability to read a private message, but I guess it is possible.

I applied patch and Im still getting watchdog not found errors for address messages/pmgrowl_json I have privatemsg 6.x-1.0-rc2.

just download the 1.x-dev nightly release - that should be fine.

nbz I downloaded 1.x-dev but this didn't help.

afaik it will not make a difference to the people who have already got the page loaded, so the effect will show after some time.

-Shaman-, what message are you getting exactly in watchdog? ..the initial error was an Access Denied, not a page not found error. Are you getting this message with a logged in user? or as an anonymous user?

It may help to use Firebug and look on the "Net" tab or the "Console" tab for errors there.

There will also still be access denied errors from authenticated users who have multiple tabs open and then log out of on one of them. I doubt we can do anything about that.

I have Acces Denied messages, I disabled module yesterday, and turned on patched version today. I'm getting those messages from both authenticated and anonymous users (I enabled privatemsg and pmgrowl only for admins for now, for testing). I even cleared sessions table, but without effect…

As I mentioned since people use multiple tabs, all the errors will not disapear...

@Dave.Ingram - is there a way to tell the script to stop looking/reloading once a user has gone offline?

-Shaman-:
After clearing the session table, do you still see errors from authenticated users?

Another possibility is that the Javascript is cached (although installing a module should clear it). Please try clearing the cache using Site Configuration -> Performance -> Clear Cache.

The most likely scenario is what nbz is suggesting that someone has left your site open in their browser and it will keep pinging for updates until a new page is requested or the browser is closed. If your errors are only from anonymous users after clearing the sessions table and the cache, this is very likely the problem. If that is the case, the best option is to wait a few days for the user to close their browser (you could also look at the IP address and see if the user is anyone you know).

I think one problem is coming from "I enabled privatemsg and pmgrowl only for admins for now" ...our check only sees if users are logged in or not, it doesn't check for permissions to use pmgrowl and privatemsg before serving up the javascript in the init_hook. I'll patch in the next day or two, but if anyone can add that in init before I get to it then I'll apply.

@nbz - as far as disabling the javascript, it is possible to cancel the timer that's pinging the server.

One thing we need to figure out is do we stop pinging at just one access denied error? ..what if there was a network error? ..should we count how many there are and cancel after X #? that would be more overhead.

There's also the request in another issue to close messages on opened tabs when they've been closed on another. This would all mean passing the required information in the json object from pmgrowl_json into the script, then running all the right logic. This would be the first step. It'll be some more overhead for the script, but I guess it shouldn't be too much.

I've got a lot of client work this week and I don't know how much time I'll have to look at this, but like I said, I'll review any patches, and if none come in I'll try to get this worked out asap.

I'm getting access denied errors also for anonymous users

The patch I posted does check for "read privatemsg" permission.

I just checked both the -dev and the -alpha1 releases and neither includes this patch. I don't know if -Shaman- applied the patch to the -dev release or not.

Regarding disabling the Javascript, I would prefer a configurable error counter with a default of 2 or 3 errors before disabling the timer.

I applied patch to dev version, seems like there is substantially less errors, but they're still appears from time to time though.

...I just checked both the -dev and the -alpha1 releases and neither includes this patch...

Just checked and that is a problem - the nightly does not seem to have automatically updated since 23 May.

The latest dev version is from May 17? Is that right?
Thanks :)

title ;-)

the latest changes were committed on June 17, so if the last updated date you see is before then, then it is old. I have gotmyself a copy from cvs that I am using.

HI nbz,
Can you please let me know how to get the latest dev from cvs... I am not sure how to do that,
Many thanks :)

Delta Bridges, nbz, et all... I've just released an alpha 2 with all the latest changes. Not sure why the nightly snapshot wasn't picking up the latest commits, but alpha 2 currently represents the most recent code available, so give that a try.

Many thanks :)

i updated to the latest version. i waited one week, cleared the cache, but the error is still happening. nothing changed :\

I am using the alpha 2 version but the watchdog when I track which pages a user has visited (track page visits) is still full of :
messages/pmgrowl_json

Detail doesn't indicate any particular errors, but if I click on the link, I am taken to an empty white page with the following: [ ]

Very strange... any help would be appreciated. This module otherwise works great and is a wonderful feature. But it is a shame one can hardly use the track visits page when it is enabled :)

Many thanks,

That is just the format that pmgrowl uses to get its info - nothing to worry about. Try visiting that page when you have unread messages to see how it would look otherwise.

and yes, pmgrowl will call that page every x seconds to see if the user has recieved a new messages - it is how this module works.

Marking as fixed as the original problem surely is and the last question was over the design of the module which is as it is.

i updated to drupal 6.13. since that the error is gone.

great module.

ah... interesting, I am still on 6.2... this could explain.
Yes, really great module.... now it is exciting to receive a pm on Drupal :)

I have 6.12 and it's ok now, so I don't believe it depends from drupal version as those are minor security updates only.

@shaman, like you i even think it doesn't depend on a drupal update but i just told you my remark. for sure there will be another way to solve this issue.

give it a try

I'm using alpha2 and my watchdog is still full of the 'messages/pmgrowl_json' access denied messages. Is there another version somewhere with this fixed?

Have the same issue in Drupal 6.14

Are you using an automated logout or something like that?

I assume this can happen when the user is automatically logged out (or logs out manually) and still has a page/window of the site open where he is logged in.

The only thing we could improve is detect the 403 in the calling JS code and stop trying when that happens.

Edit: That would mean that you only get a single 403 per user/window in such a case.

This is not fixed, we really need something for this. I am aswell getting the 404 since short (since truncating sessions table).

What could i do, since i really like to have my log on (which now is off)

cant i drop a die; somewhere in pmgrowl.js ?

This is to be expected I guess.

The only thing we could do is detect a 403/404 and stop the execution. But clearing the session table means that all users who still have the page open will continue to try and log in until they close it or click on a link.

I want to report that this issue is still very much active even with the recent 7.x-1.x-dev (2013-Oct-01).
The watchdog is full of Access denied messages for messages/pmgrowl_json for anonymous users.

Please suggest what to do?

If anyone is still having problems with this (Not sure if this is a good thing to do) I gave anonymous user Read private messages and the error is now gone. Not the best way to go, but its an internal site so I think I can get away with it.

My redneck solution: In root make this: messages/pmgrowl_json/index.html for index.html just put html template, then in drupal aliases rename /messages into messages/fix that /fix bit is important it can be named differently but it must be subfolder otherwise it will be back to square one, and that's all folks, git-r-done!