Chatroom kicked out on Join problem

I can't reproduce this behavior. This bug report will be closed unless I get confirmation that it occurs with the current version.

This happens to me too, I have 4.7 and have installed the whole lot as per instructions - enter chatroom, nothing happens then I get kicked.
I'm using Firefox and had the same behaviour under windows & linux

here's my test install.

http://www.fatinternetkid.com/active/

As soon as we can fix this bug, I'll make a 4.7 release.

Thanks Dazza,
I've literally been checking cvs messages every week hoping this will get resolved - as such I've been holding out deployment of drupal. You are a lad.

timl, how long have you been running chatroom? Have you updated it since the first time you installed it? Some revisions break previous installations. You can try deleting and recreating your chatrooms; if that doesn't work, you will need to disable the chatroom module, delete the chatroom tables from your database and the chatroom row from your system table, then re-enable the chatroom module. I recommend that everyone do this when installing updates until a stable version is released.

Feel free to re-open this issue if following these instructions doesn't fix the problem.

Again, it's still no good for me..

Completely removed it from http://www.fatinternetkid.com/active (deleted files/directories/tables & entry in system table), reinstalled with same problem

Dropped this onto another one of my sites - Drupal 4.7, (non-CVS) http://www.webzillionaire.com
fresh install onto pristine 4.7.. And I'm getting kicked.

Your dev room works fine under my browser/OS (Firefox 1.5/Ubuntu)

Cheers

I also have the same issue. Using both the latest version of Drupal and the most updated version of this module, just downloaded and installed today. I can create and edit rooms, but as soon as I enter I am kicked out.

chatroomread makes some unecessary assumptions about its path and scream's 'UR3l33t' if it finds a problem. just search for that string in chatroomread. that might be the problem. we tried to fix it in http://drupal.org/node/75475 but the code still looks ugly and maybe wrong.

I'd like to get more information before I pursue this. Does this problem affect only those who have installed chatroom in their sites directory? Are there any error messages in the log?

No, I'm using the latest chatroom module through the module directory, but I'm still facing the same problem, i.e. kick on join. I'm the admin, and I've even tried possible combos of the access control, but I'm kicked out always.

ditto, clean 4.7 install - chatroom untarred into module directory
module enabled, admin then kicked from all chats on entry..

chatroomEjectUser is not defined line 67?

Ah, thank you. Finally something I can look into. Does it make a difference what version of PHP you are using? (Instructions for checking your PHP settings are here.)

I get the kicked out message on my webhost, which uses PHP version 5.1.1 and MySQL version 4.1.15 on a FreeBSD 5.4.

Now I created a sandbox setup of Drupal on my local machine using PHP version is 5.1.6 and MySQL version is 5.0.24a (using XAMPP) and the Chatroom module seems to work fine there.

Ok this is just useless, I accidently changed the whole damn issue's name, so this is a follow up to change it back again.

I'm using PHP 4.4.4 with MySQL 4.1.21 and have no problem. Anyone who would like to check can look at my configuration.

I also am getting this error. Have there been any updates?

My Host setup:

PHP v 5.1.5
MySQL 4.1.21

Apache 2.0.52

RedHat linux

Thanks.

Chris

All the problem sites appear to be running on PHP5. The test site runs on PHP4.

HI Darren,
When I click on your configuration link in the post above, the php_info() looks like it is 5.1.6.

Is this correct?

Thanks.

Chris

My hosting provider must have upgraded to PHP5 within the last day or so. My Chatroom installation still works. I guess that saves us from hunting for a problem with PHP5 compatibility.

OK saga continues.

I uninstalled chatroom ( I had it installed in drupal/modules)

Resinstalled to drupal/sites/default/modules and it worked -- sort of.

I can see the window, but when I enter the text and press send,

message disappears and nothing is written to chat window.

What could I be missing?

It looks like there are some files written to the cache directory, do they need any special permissions?

Definitely getting closer.

Thanks.

Chris

cgseymour - the bevaior you describe when installing in sites directory is fixed by a patch i uploaded yesterday.

folks having this problem should ideally disable all other contrib modules and use a core theme and see if tghe problem goes away. might be anodd interaction with a contrib module. i see google analytics is installed on the site named here. a red flag IMO, since the both call home via javascript.

HI moshe,
Please forgive my ignorance, but how would I apply such a patch and where could I get it from?

Thanks.
Chris

Moshe is referring to the patch in issue 88300. There are instructions for applying patches in the Drupal handbook.

OK guys,
I got the patch and applied it locally then copied the 2 patched files to my server. I am back to getting the kicked out for being naughty message.

Any ideas?

Thanks.

Chris

Send me (privately) a list of the modules enabled on your site and I will test.

Nobody has mentioned any error messages. Are there any? Check your logs. Any clues would help.

No error logs. Just normal kick out. I tried removing all useless modules, to make the site more slim but to no avail.

well, same problem here... see http://basoofka.net/kanciapa for test, site runs on php 4.3.10, with lots of modules, but for suprise, on my localhost test site with PHP 5.1.4, and very similar set of modules, it runs just fine!

So, here you are - list of modules on localhost: activemenu, , ajaxsubmit, archive, bbcode, block, blog, chatroom, collapsiblock, comment, comment_mover, contact, contemplate, content, drupal, filter, flatforum, forum, help, imagefield, jstools, link, locale, masquerade, mediumvote, menu, node, nodefamily, nodeprofile, nodereference, number, optionwidgets, page, pageroute, path, poormanscron, privatemsg, profile, quicktags, quote, search, shoutbox, similar, site_user_list, smileys, story, subscriptions, syndication, system, taxonomy, text, tracker, upload, user, user_badges, user_search, usernode, usernodes, userreference, views, views_rss, views_theme_wizard, views_ui, votingapi, watchdog, xtracker,

and on remote (chat not working) site: activemenu, adminblock, archive, article, backup, bbcode, block, blog, chatroom, collapsiblock, comment, comment_mover, contact, contemplate, content, drupal, fileshare, filter, flatcomments, flatforum, forum, help, imagefield, jstools, link, locale, masquerade, menu, node, nodereference, number, page, path, poormanscron, privatemsg, profile, quicktags, quote, search, shoutbox, similar, smileys, statistics, story, subscriptions, system, taxonomy, text, tracker, upload, user, user_badges, userreference, views, views_rss, views_theme_wizard, views_ui, watchdog,

I'll try to do some tests and get back if i find anything

ops i just saw that this is cvs topic, i have drupal 4.7.3+chatroom 4.7 versions (chat room from today)... one hint - my site basoofka.net is drupal installed in subdirectory, and domain is redirected to this subdirectory (i dont know how exactly, normally my site was visible as basoofka.net/subdir, but after redirecting from admin panel of my webhost it is just basoofka.net - maybe sth with urls?)

Testing revealed that if i enter chat and click STOP button fast, i got kicked on next server request (if i set this to 10 secs, it will kick me after 10 secs)

After extensive testing, no one has been able to reproduce this behavior consistently. The problem may be the server's configuration rather than the Chat Room code. There is a note on this topic on the Drupal Chat group page.

Since I do not have access to a server that exhibits this behavior, there is nothing I can do. I see that slidenby@gmail.com has assigned this issue to himself, but he is apparently no longer involved. I'm closing this issue. If someone figures out how to solve the problem, please create a new issue.

I came across a few errors while cleaning up the code. I'm surprised the module worked.

I still have this problem with the latest release of the module.

PHP 4.4.2
MySQL 5.0.16
Drupal 4.7.3

I'm willing to help out if you need any more info.

I'm completely baffled. None of the developers are having this problem. I will accept a patch for this issue, or fix it myself if anyone can track down the source of the problem.

As of about 4 days ago on a fresh install of 4.7 and the latest linked version of Chat Room I'm getting the exact same problem as everyone else here. My install is at www.technospider.com/cms/

I would like to track down the source of this problem, but I haven't been able to reproduce it and don't have access to a system that has the problem. If someone would like to volunteer a system for me to troubleshoot, please contact me privately.

I've been troubleshooting on technospider.com, and found a problem with the chat cache path. The patch has been committed, but I haven't been able to test it on technospider.com yet. I would appreciate it if others who have the problem would report their results.

The server in question is owned by my employer, so I can't give you access, but I applied the patch and am getting the same behavior :(. Thanks for working on this! I'll test any patch you throw at me.

Thanks to David Muszynski, I've had the opportunity to work with a site that has this problem. The page doesn't seem to communicating with chatroomread.php. I would say there is a problem with the path in one of the JavaScript functions, but I don't know how to view values in JavaScript, and tracing values from one function to another is like following spaghetti.

there are a couple extensions for firefox which sometimes help with these bugs. see venkman and firebug. both take a little getting used to.

Thanks, Moshe. I was able to debug using venkman. What I found was that on David's server every update request gets a kickuser response from the server. The happens when the user requesting the update is not registered in the chat. So now I have to figure out why this particular server won't recognize anyone as a member of the chat.

By the way, my name shows up in the chat online users block, so I am being registered, just not recognized by the textentry area.

Hi darren , I'm Italian.
Sorry for me english.

I have same problem , the chat just entered , kick me out.
My site , is on altervista.org.

I tried the patch in this section , but nothing.
Is this a big problem?the chat is very beatiful e i would use in my site.

Bye,Dario

I have not been able to identify the cause of this problem, but here is what is happening. Maybe someone else can explain it.

The browser requests a chat update from the server when the page loads. It's a post request that contains the following query string:

"online_list=1&chatroom_base=modules%2Fchatroom&update_count=30&user_base=modules&chat_id=1&last_msg_id=0&timezone=-18000&timestamp=1163981090&chat_cache_file=%2Ftmp%2Fdrupal_chat_cache%2Fchat_1"

chatroomread.php processes the posted variables and passes them to the chatroom_chat_read_msgs function in chatroom.module. chatroom_chat_read_msgs calls chatroom_chat_is_registered_user to see if the user is a member of the chat.

Here's the response from the server to the values from the query:

$chatroom_base = modules/chatroom
current directory = /Users/david/Sites/technospider
$user_base = modules
$chatroom_module_file = ./modules/chatroom/chatroom.module
$user_module_file = ./modules/user.module
Are we writing? No.
$browser_timestamp = 1163961771
$update_count = 946
$chat_id = 1
$last_msg_id = 0
$chat_cache_file = /tmp/drupal_chat_cache/chat_1
$online_list = true
$timezone = -18000
read response: [{msgs:[{id:1,text:"Display this!",user:"Darren Oh",time:"19:53",recipient:"",type:"msg"},{id:2,text:"Display this!",user:"Darren Oh",time:"19:59",recipient:"",type:"msg"},{id:3,text:"Display this!",user:"Darren Oh",time:"20:00",recipient:"",type:"msg"},{id:4,text:"Display this!",user:"Darren Oh",time:"20:00",recipient:"",type:"msg"},{id:5,text:"Display this!",user:"Darren Oh",time:"20:01",recipient:"",type:"msg"},{id:6,text:"Display this!",user:"Darren Oh",time:"20:03",recipient:"",type:"msg"}]}, [] ,{cacheTimestamp:1163984612}]

That's the response I get from my servers and when I manually set the values in chatroomread.php on a problem site. However, if I let chatroomread.php get the same values from the HTTP post, this is the response I get on a problem site:

"[{kickUser:'5c2e00756f9ae636c6e5a2fd876f7689'}]"

I have no idea what is happening to the variables in between the browser and a problem server.

A little more information:

The kick response is generated when chatroom_is_registered_user does not recognize the user. However, looking at the database table, I see that the user is registered for the chat. That means the chat_id variable is not getting through. I commented out the lines that check to see if the user is registered in the chat. That stops users from being kicked, but no messages get through. So something must be happening to the posted variables in between the browser and the server on sites that experience this problem.

For testing, I modified chatroomread.php to send the value of $_POST['chat_id'] as a message. I expected to receive an empty value. Instead, the correct value was displayed. So my theory that in some cases the values posted by the browser don't make it through the server is wrong.

Three things could cause chatroom_is_registered_user to generate a kickUser message:

1. A chat ID that is missing or doesn't have a match in the chatroom_chat table,
2. An session ID that doesn't match the value in the chatroom_chat table, or
3. An inability to read the correct values from the chatroom_chat table.

I have already verified that the session ID generated by the server matches the session ID in the chatroom_chat table. I have also verified that the chatroom_chat table contains the correct chat ID. Now I have verified that the server is receiving the chat ID correctly.

chatroom_is_registered_user returns a correct answer when I give it the correct parameters. In between chatroomread.php and chatroom_is_registered_user is the chatroom_chat_read_msgs function if we are reading or the chatroom_chat_write_msgs if we are writing. Since all the other parts are working, and neither reading nor writing are successful using these two functions, my only guess is that there is something in these two functions that doesn't work properly on some servers.

The problem has to be near the beginning of each of these functions, because the first thing they do is call chatroom_is_registered_user.

The problem turns out to be this: on some sites, the variables set before the drupal_bootstrap (line 111 in chatroomread.php) are unset when drupal_bootstrap is executed. I don't know why.

Hi darren.
READ THIS .IS IMPORTANT.IM ITALIAN , if YOU CAN TRANSLATE.:

Ho usato la chat e nn funzionava.Poi ho installato dei moduli , e una volta rimessa funzionava.
Dopo di che ho settato delle cose , cm i nomi delle chat o le stanza e nn funzionava piu.

Spiacente, Darios. Non potrei tradurre queste parole:

nn
settato
cm
piu

Translation of darios81's sentence:
"I've installed the Chat room module and it didn't run. I then installed other modules and re-installed Chat room module and it did run. After that I tuned up some settings, as names of chats or chatrooms and the module didn't run anymore."
I hope this can help.

I have the same problem "kicked out of the chatroom".
Here is my phpinfo()...
http://test.bandadarfo.eu/info.php

max

HI , thank Max.
Read here is very important.

I have installed last version of Chatroom yesterday night.
Surprise , the chat room functioned.

After this mornig , try , and not function the chat room.
Incredible.Yesterday , yes , today , no.

There are two ways to fix this problem:

1. Remove "register_globals = on" from your php.ini file.
2. Remove "AllowOverride None" from your Apache configuration.

Thanks to Moshe Weitzman for explaining Drupal's bootstrap.inc file to me. Many thanks also to David Muszynski for giving me access to his server so I could track down this problem.

Here is a more detailed explanation for those who are interested:

Line 111 of chatroomread.php executes drupal_bootstrap. drupal_bootstrap executes the function drupal_unset_globals on line 137 of the file bootstrap.inc. This function checks to see if the PHP setting "register_globals" is on. If so, it unsets most variables. This is a security feature to prevent variables from unknown sources from being injected into your code. See the PHP manual for information about why this is necessary.

Normally, drupal_unset_globals does not have to unset variables, because even if "register_globals = on" is set in your php.ini file, it will be overridden by Drupal's .htaccess file. But, if "AllowOverride None" is set in your Apache configuration, Drupal's .htaccess file is ignored. See the Apache documentation for information about the AllowOverride directive.

If "register_globals = on" is set in your php.ini file and "AllowOverride None" is set in your Apache configuration, all variables set before line 111 of chatroomread.php are unset.

I don't mean to keep bothering you with this problem, because I really appreciate the amount of time you've put into it. You can close this bug again if you want and I won't make a stink about it.

That said, if the problem is with code written for register globals off not working with register globals on, it can be fixed pretty easily. And since the configuration you talk about is used on lots of shared hosts, why not fix it?

Here's a patch of chatroomread.php that works fine for me. It definitely could be cleaner, but I didn't want to mess with any of the logic. So I just have a bunch of variable assignments to make sure the necessary variables are always available.

Hope this helps, and thanks again for all your time on this issue, I never could have created this patch without your last post.

Thanks for the patch. This saves me from having to write a complicated INSTALL.txt. I had tried setting the variables after line 111 but was under the impression that it then stopped working with register_globals off. I checked again and found I was wrong, so this patch is ready to go in.

The whole chatroomread.php file could be cleaner, but I haven't had time to analyze what it's doing.

Patch applied in CVS commit #45956.