Hi All,
Using the latest 1.4 development nightly (and the one before that) I'm seeing a weird problem whereby I can start up a browser, log on to our moodle as the site admin, moodle around for a bit, and then, all of a sudden, moving from one place to another, suddenly find myself logged on as someone else. Another user that is currently logged on, that is. It is like I am picking up their session.
Give you an example. I have two PCs here. I was logged on one as the admin, and on another as my test student. Admin is Firefox 0.9, test student in IE6.
Attempt to switch on editing, and find myself suddenly logged on as the test student, where I was previously logged on as the Admin.
Very very odd...
Any pointers at where I should be looking?
This is the machine I've just built...clean install of moodle, and then all the courses transferred from the old system using the backup / restore process.
Sean K Beardie
Firstly, this is most likely a PHP sessions problem, not related to the clients. What version of PHP are you running? Try a newer one. 
Secondly, there is a very remote chance that the cookies are being cached in a common proxy of some kind (between the server and the clients). This is obviously bad behaviour for a proxy but I have seen it before.
Secondly, there is a very remote chance that the cookies are being cached in a common proxy of some kind (between the server and the clients). This is obviously bad behaviour for a proxy but I have seen it before.
I thought it was probably sessions.
Using PHP 4.3.4 on Apache 2.0.48
No proxy involved whatsoever.
It has just happened again. Wasn't logged onto moodle anywhere...started up a browser, pointed it at the site and lo and behold I was already logged on as Oliver Hutton (one of our students). Refreshing the browser didn't make any difference.
Most odd...
Sean K Beardie
Using PHP 4.3.4 on Apache 2.0.48
No proxy involved whatsoever.
It has just happened again. Wasn't logged onto moodle anywhere...started up a browser, pointed it at the site and lo and behold I was already logged on as Oliver Hutton (one of our students). Refreshing the browser didn't make any difference.
Most odd...
Sean K Beardie
If you look in the $CFG->dataroot/sessions folder you should see the active sessions (look inside them if you want to see the actual data). These are the files that PHP uses to maintain session data.
Needless to say (but I'll say it anyway) these do not usually get confused with each other. I don't have any more clues as to what could be causing this on your server ... if I was in your shoes I would upgrade PHP to a later version just in case.
Needless to say (but I'll say it anyway
It certainly is weird.
I'll upgrade PHP when I get the chance, certainly. I just don't see why I should start getting the problem on 4.3.4 when I've been running it on the old server with never a hint of this problem.
I'm expecting it to be something that I have done...or not done, if you see what I mean...I just can't see what.
But hey, it's a dev version anyway, so weirdness is expected
Sean K Beardie
I'll upgrade PHP when I get the chance, certainly. I just don't see why I should start getting the problem on 4.3.4 when I've been running it on the old server with never a hint of this problem.
I'm expecting it to be something that I have done...or not done, if you see what I mean...I just can't see what.
But hey, it's a dev version anyway, so weirdness is expected
Sean K Beardie
Hi Sean and Peter or anyone,
Have you had any luck with resolving this issue? I am still having problems in that if two students are logged in at the same time, sometimes they are switched and logged in as the other person. As you can imagine, this causes havoc.
I am running
Moodle 1.3.3 on
Apache 1.3.31
PHP 4.3.8
I have modified every setting that seems applicable within the PHP sessions - nothing has worked yet. We are behind a proxy server that will then send the http requests to the exact server that Moodle is loaded on. All the IP addresses in the log file are coming from the proxy server instead of the studen't actual login. Is this helpful info to finding a solution?
Thanks for any help.
Have you had any luck with resolving this issue? I am still having problems in that if two students are logged in at the same time, sometimes they are switched and logged in as the other person. As you can imagine, this causes havoc.
I am running
Moodle 1.3.3 on
Apache 1.3.31
PHP 4.3.8
I have modified every setting that seems applicable within the PHP sessions - nothing has worked yet. We are behind a proxy server that will then send the http requests to the exact server that Moodle is loaded on. All the IP addresses in the log file are coming from the proxy server instead of the studen't actual login. Is this helpful info to finding a solution?
Thanks for any help.
Hi Kirsten,
In my case, it seemed to be a problem with the Apache 2 version of the PHP module (or some other weirdness in Apache 2). I switched back to Apache 1.3.x and the problem went away.
However I see that you are already running apache 1.3.x so obviously my fix doesn't apply to you
I know that this doesn't seem to have any bearing on the problem, but have you considered moving up to Moodle 1.4.1? That is the latest release, as of yesterday, and may help...(you never know until you try).
Make sure that you have a good backup first of course.
Sean K Beardie
In my case, it seemed to be a problem with the Apache 2 version of the PHP module (or some other weirdness in Apache 2). I switched back to Apache 1.3.x and the problem went away.
However I see that you are already running apache 1.3.x so obviously my fix doesn't apply to you
I know that this doesn't seem to have any bearing on the problem, but have you considered moving up to Moodle 1.4.1? That is the latest release, as of yesterday, and may help...(you never know until you try).
Make sure that you have a good backup first of course.
Sean K Beardie
Hi We are experiencing the same problem,
I had previously tried to fix it by
1) Removing the proxy server server
2) Removing NAT from the equation
the problem appeared to go away for a bit but has from time to time comes back usually when there are a lot of simultanious logons IE A computer lab.
Unfortunatly this is a production system so at this point have not run any updates but that is my next course of action
At the moment I'm running:
Moodle 1.3.1
Apache 2.0.48
MySql 4.0.18
PHP 4.3.4
I have noticed that this problem has been reported before and no resolv was ever posted, I dont believe its specific to the delelopment version of moodle, if I manage to get it going properly i'll post my solution.
If anybody has any suggestions plase let me know also.
Peter Davis.
Just an update on my progress I have downgraded PHP from 4.3.4 -> 4.3.3 and Updated moodle to the latest stable build as of 17th Aug 04 (1.3.4 + (2004052504)). I attended a class who had a lab full of students and so far no symptoms of the problem. I'll know for sure in a day or two if the session problem is cured.
Hope this is usefull.
I am experiencing the same thing. See discussion thread http://moodle.org/mod/forum/discuss.php?d=10665
What we have found is that the sessions are being created when someone logs in, but are not being deleted properly. Is this a PHP or Moodle thing? Would it be possible to change the location of where Moodle stores the sessions? Instead of in the dataroot directory, have Moodle save the sessions in the default PHP directory?
Thanks for your help.
Well, now, for the first time I have actually seen this happen on one of my own servers. You can actually see in the logs how the person morphs from one person to another (the IP address remains constant).
Needless to say even if it happens only rarely it's a bit of a worry!
I'm almost 100% certain that this is a PHP bug with sessions and nothing to do with Moodle or Apache.
This is how sessions work:
Now what seems to be happening is that sometimes the wrong file is being selected for a particular user, or perhaps that the updating of the files is sometimes getting confused when trying to write two at the same time.
I don't have any answers for this one, and after a quick look I haven't found anything yet in bugs.php.net ... all help would be very welcome !
(Edited to fix link)
Needless to say even if it happens only rarely it's a bit of a worry!
I'm almost 100% certain that this is a PHP bug with sessions and nothing to do with Moodle or Apache.
This is how sessions work:
- The first time you connect to the web server, PHP creates a random session name that looks like this - c262d0fd3ec27b5119654e7607350539 - and sends it to your browser as a session cookie.
- At the same time, it creates a file on the disk with the same name, eg "sess_c262d0fd3ec27b5119654e7607350539". You can find these in moodledata/sessions.
- Every time you visit a page in the site, your browser sends the session cookie back to PHP.
- PHP uses this cookie to open the little file, and makes the 'session data' inside it available to the currently running scripts.
- When the script finishes (and the session data has possibly been updated) the file is written back to disk.
- Thus we can keep persistent information in the file that is available for the whole session. For example, when you actually use the login form, your user details are stored in the session (ie in this little file) and so all the later scripts know that you are logged in as such-and-such.
Now what seems to be happening is that sometimes the wrong file is being selected for a particular user, or perhaps that the updating of the files is sometimes getting confused when trying to write two at the same time.
I don't have any answers for this one, and after a quick look I haven't found anything yet in bugs.php.net ... all help would be very welcome !
(Edited to fix link)
This is worrisome - suppose a student morphs into a teacher or an admin. Even students morphing into each other would cause a lot of confusion.
How can you tell from looking at the logs that this might be happening? I've run a query against the logs, looking for cases where the userid changes within 5 minutes from the same ip. I notice a lot of apparent false positives:
How can you tell from looking at the logs that this might be happening? I've run a query against the logs, looking for cases where the userid changes within 5 minutes from the same ip. I notice a lot of apparent false positives:
- users morphing to and fro the guest user
- users using a public computer lab
- a pair of users apparently sharing a single ip, perhaps behind a common router
- users using the same proxy
Hello all,
I have been working (well, actually it seems more like managing the damage control) on this problem for several weeks. I haven't come up with a solution yet either or a specific cause, but I thought I would add to this discussion in hopes that it would be helpful. It is particularly difficult when I cannot duplicate the error, it is a synchronous problem, and it is on a production server. Anyhow, thanks for all the suggestions and I'd be happy to help in any way that I can!
Zbigniew, it is worrisome in that we did have a student morph into a teacher actually. Luckily the student was unaware and I now have all the teachers not stay logged in for long idle periods.
Thanks Sean for your suggestion of moving to 1.4.1.
So, an update on the idea that I have posted before.
I had been thinking that PHP was not deleting the sessions properly and thus they were/are accumulating in the moodledata/sessions directory. I don't know whether or not this is the problem source. I modified the directory where Moodle saves sessions, but since I am not able to duplicate the problem on command, am not sure if this is helping. The session file accumulation is still happening though and then PHP either finally cleans things out or I manually clean out the directory. I think Martin is probably right with his thinking - that it is a problem when PHP is trying to write two session files at the same time...
My server system is set up with a proxy layer, so there is often the case that students seem to be logged in under the same IP. I notice often in the code, the HTTP_REFERER is used and for my server, it then sends the proxy IP address. Is this related or helpful?
I will continue to monitor things and if I can find any patterns I will share them. I would be interested in any information about what to look for in the server logs.
Thanks so much.
I have been working (well, actually it seems more like managing the damage control) on this problem for several weeks. I haven't come up with a solution yet either or a specific cause, but I thought I would add to this discussion in hopes that it would be helpful. It is particularly difficult when I cannot duplicate the error, it is a synchronous problem, and it is on a production server. Anyhow, thanks for all the suggestions and I'd be happy to help in any way that I can!
Zbigniew, it is worrisome in that we did have a student morph into a teacher actually. Luckily the student was unaware and I now have all the teachers not stay logged in for long idle periods.
Thanks Sean for your suggestion of moving to 1.4.1.
So, an update on the idea that I have posted before.
I had been thinking that PHP was not deleting the sessions properly and thus they were/are accumulating in the moodledata/sessions directory. I don't know whether or not this is the problem source. I modified the directory where Moodle saves sessions, but since I am not able to duplicate the problem on command, am not sure if this is helping. The session file accumulation is still happening though and then PHP either finally cleans things out or I manually clean out the directory. I think Martin is probably right with his thinking - that it is a problem when PHP is trying to write two session files at the same time...
My server system is set up with a proxy layer, so there is often the case that students seem to be logged in under the same IP. I notice often in the code, the HTTP_REFERER is used and for my server, it then sends the proxy IP address. Is this related or helpful?
I will continue to monitor things and if I can find any patterns I will share them. I would be interested in any information about what to look for in the server logs.
Thanks so much.
I've started logging session ids in the Moodle logs. Here is what I did. First using phpMyAdmin (the one from the Moodle downloads page), I added an extra column called session to the mdl_user table. I set the column to have type VARCHAR of length 64. Leave the rest of the column creation form with their default values.
Then I made a slight modification to lib/datalib.php in the following function:
I will post code to analyze the Moodle log table to check for this problem in another post.
Then I made a slight modification to lib/datalib.php in the following function:
function add_to_log($courseid, $module, $action, $url="", $info="", $cm=0, $user=0) {
global $db, $CFG, $USER, $REMOTE_ADDR;
if ($user) {
$userid = $user;
} else { if (isset($USER->realuser)) { // Don't logreturn;
}
$userid = empty($USER->id) ? "0" : $USER->id;
}
$timenow = time();
$info = addslashes($info);
$result = $db->Execute("INSERT INTO {$CFG->prefix}log (time, userid, course, ip, module, cmid, action, url, info, )
VALUES ('$timenow', '$userid', '$courseid', '$REMOTE_ADDR', '$module', '$cm', '$action', '$url', '$info', '')");(Modifications marked in red.)I will post code to analyze the Moodle log table to check for this problem in another post.
Here's the script to analyze your Moodle logs to check for the session morphing problem. It assumes you made the changes suggested in the above post -- it won't work otherwise.
Thank you very much. I'll implement this and see what happens.
The proxy might be the culprit, rather than PHP or Moodle. The proxy might be sending pages intended for one user to another user. If that's the case, the session information that I suggested you add to the Moodle logs won't show anything wrong.
I also wonder if a malfunction of PHP caching software on the server might lead to these kinds of problems?
In another vein, I analyzed the Moodle logs on my server and turned up two oddities (out of about 1.3M entries). There are two cases where there are two pairs of entries in the logs spaced about a minute or two apart, from the same IP, but with different users. Moreover in each case, all but one log entry from that IP is associated to one of the users in the pair. In both cases the other user in the pair has only that single odd entry in all of the Moodle logs. Moreover one of these users is marked as unconfirmed and deleted and has no identifying information. These log entries date from autumn 2003, when I was running Moodle 1.1.1. Also both log entries from the strange users show that the associated url was user/view.php?id=###&course=1
I also wonder if a malfunction of PHP caching software on the server might lead to these kinds of problems?
In another vein, I analyzed the Moodle logs on my server and turned up two oddities (out of about 1.3M entries). There are two cases where there are two pairs of entries in the logs spaced about a minute or two apart, from the same IP, but with different users. Moreover in each case, all but one log entry from that IP is associated to one of the users in the pair. In both cases the other user in the pair has only that single odd entry in all of the Moodle logs. Moreover one of these users is marked as unconfirmed and deleted and has no identifying information. These log entries date from autumn 2003, when I was running Moodle 1.1.1. Also both log entries from the strange users show that the associated url was user/view.php?id=###&course=1
Mmmm... How would I test out the PHP caching software? Isn't it embedded within PHP?
There is a chance that I can install Moolde on another system that does not have this same proxy layer. However, I seemed to have read that a few others have had this problem and one said that removing the proxy layer did not help.
I'll keep on trying!
There is a chance that I can install Moolde on another system that does not have this same proxy layer. However, I seemed to have read that a few others have had this problem and one said that removing the proxy layer did not help.
I'll keep on trying!
As Martin and others indicated, all the eyes are on PHP session management code. I have a few questions in this regard.
- Version of PHP
- Platform (OS and webserver)
- If you are running apache 2.x whether you are using it with threads
- What options for session management have you got setup? Does it still happen if you change your session management to be on mysql? If you are using files, what filesystem is it?
- Is it possible there there is a _transparent_ proxy around mucking things up?
As you can see, the suspicious areas are:
- The possibility that PHP is mucking up things if running threaded (under IIS or Apache2)
- The possibility that the storage for sessions is messing up (the filesystem, or IPC, or mysql)
- Proxies, damn proxies...
cheers,
martin
- Version of PHP
- Platform (OS and webserver)
- If you are running apache 2.x whether you are using it with threads
- What options for session management have you got setup? Does it still happen if you change your session management to be on mysql? If you are using files, what filesystem is it?
- Is it possible there there is a _transparent_ proxy around mucking things up?
As you can see, the suspicious areas are:
- The possibility that PHP is mucking up things if running threaded (under IIS or Apache2)
- The possibility that the storage for sessions is messing up (the filesystem, or IPC, or mysql)
- Proxies, damn proxies...
cheers,
martin
- Version of PHP
PHP 4.3.8
Moodle 1.3.3 (haven't yet upgraded to 1.4.1 because a course was/is live)
MySQL 4.0.17
- Platform (OS and webserver)
I believe the machine is Sun Ultra 250 running Solaris 8
Apache 1.3.31
- What options for session management have you got setup?
Which PHP session flags are you interested in? I don't want put something up unnecessarily.
Does it still happen if you change your session management to be on mysql?
If you are using files, what filesystem is it?
I haven't changed the session management to be on mysql yet - I'm not sure how this is done. We are using files, i.e. session.save_handler = files.
- Is it possible there there is a _transparent_ proxy around mucking things up?
I met with our server admin folk Monday, and the way it was explained to me is that the http requests go to a node cluster with 7 separate IP addresses (this is the proxy layer). This cluster then will send the request directly to the server where Moodle is installed. This is a dedicated server just for this software.
I hope this is helpful information. I'm willing to try anything.
Hi all,
I'm experiencing the same random user session jump problem on a new Moodle server I've just installed and we are going to use soon.
As Martin and others indicated, all the eyes are on PHP session management code.
IMHO: it sounds strange to me, as there is no word about this problem in the (very large) PHP community.
Anyway...
This is my configuration:
- Version of PHP
PHP 4.3.8 from Linux Mandrake compiled distribution
- Platform (OS and webserver)
Mandrakelinux release 10.1 (Official) for i586
- If you are running apache 2.x whether you are using it with threads
I'm not an Apache expert. I'm using the standard Mandrake AdvancedExtranetServer vers. 2.0.50
It is compiled with:
- What options for session management have you got setup? Does it still happen if you change your session management to be on mysql? If you are using files, what filesystem is it?
I'm using the standard filesystem sessions.
Sessions are stored in moodledata dir as default.
moodledata directory is owned by apache:apache and world writeable
- Is it possible there there is a _transparent_ proxy around mucking things up?
No. It is not.
I saw the problem working with two browsers (different user) on the same workstation in the server LAN (no interposing firewall or proxy) and on a PC accessing from the Internet (passing only firewalls - no proxy - no application level firewalls).
And...
Moodle 1.4.2+ (2004083129)
mysql Ver 12.22 Distrib 4.0.20, for mandrake-linux-gnu (i586)
Hoping to be usefull...
I'm experiencing the same random user session jump problem on a new Moodle server I've just installed and we are going to use soon.
As Martin and others indicated, all the eyes are on PHP session management code.
IMHO: it sounds strange to me, as there is no word about this problem in the (very large) PHP community.
Anyway...
This is my configuration:
- Version of PHP
PHP 4.3.8 from Linux Mandrake compiled distribution
- Platform (OS and webserver)
Mandrakelinux release 10.1 (Official) for i586
- If you are running apache 2.x whether you are using it with threads
I'm not an Apache expert. I'm using the standard Mandrake AdvancedExtranetServer vers. 2.0.50
It is compiled with:
-D APR_USE_PTHREAD_SERIALIZE
-D APR_USE_FCNTL_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
- What options for session management have you got setup? Does it still happen if you change your session management to be on mysql? If you are using files, what filesystem is it?
I'm using the standard filesystem sessions.
Sessions are stored in moodledata dir as default.
moodledata directory is owned by apache:apache and world writeable
- Is it possible there there is a _transparent_ proxy around mucking things up?
No. It is not.
I saw the problem working with two browsers (different user) on the same workstation in the server LAN (no interposing firewall or proxy) and on a PC accessing from the Internet (passing only firewalls - no proxy - no application level firewalls).
And...
Moodle 1.4.2+ (2004083129)
mysql Ver 12.22 Distrib 4.0.20, for mandrake-linux-gnu (i586)
Hoping to be usefull...
Lorenzo
Hi!
Here is a little script that should help with testing of sessions. Unpack the file to your moodle root and open it in browser from several computers using different user accounts.
How it works: the page is repeatedly reloaded and original user (passed as page parameter) is checked against information from session. If they do not match, the script throws an error. If you want to really stress the server, comment out the sleep command
skodak
<?php
require "config.php";
require_login();
optional_variable($username, '');
$username = strip_tags($username);
print_header();
if (!$username) { //first visit to page
$username = $USER->username;
echo 'The puprose of this script is to test the sessions...<br /><br />';
echo 'You are user: '.$username.'<br />';
echo 'Press <a href="sessiontrap.php?username='.$username.'">here</a> to start the session trap.';
} else if ($username != $USER->username) { //error - incorrect cookie!!!
error('Starting USERNAME was "'.$username.'", now it is "'.$USER->username.'" ?!?!');
} else { //ok - redirect to self again
sleep(1); //comment it out if you want to stress test the server
redirect ('sessiontrap.php?username='.$username);
}
?>
Here is a little script that should help with testing of sessions. Unpack the file to your moodle root and open it in browser from several computers using different user accounts.
How it works: the page is repeatedly reloaded and original user (passed as page parameter) is checked against information from session. If they do not match, the script throws an error. If you want to really stress the server, comment out the sleep command
skodak
<?php
require "config.php";
require_login();
optional_variable($username, '');
$username = strip_tags($username);
print_header();
if (!$username) { //first visit to page
$username = $USER->username;
echo 'The puprose of this script is to test the sessions...<br /><br />';
echo 'You are user: '.$username.'<br />';
echo 'Press <a href="sessiontrap.php?username='.$username.'">here</a> to start the session trap.';
} else if ($username != $USER->username) { //error - incorrect cookie!!!
error('Starting USERNAME was "'.$username.'", now it is "'.$USER->username.'" ?!?!');
} else { //ok - redirect to self again
sleep(1); //comment it out if you want to stress test the server
redirect ('sessiontrap.php?username='.$username);
}
?>
Hi Everyone:
I have been re-directed to this discussion because I raised this problem in the forum on 'General Problems'. I am a relatively new user to the platform and overall have been very impressed with it.
My question to this group is whether anyone has actually solved the problem. I noticed that a number of people who originally posted comments and who have been experiencing this problem have not replied for a while.
I am actually in the design phase of my courses and am quite anxious to put them up but want this problem solved first. Given that I am working with high school students I am quite concerned that it could be used in a very inappropriate way. I also believe that it is very important to get the right start when introducing a CMS and many of my studenst have not used one before.
I like the comments that have been made but it does not appear that anyone has actually solved the problem. It certainly begs the question as to why this problem is happening with a few of us but not others, so in closing....
HELP!
Gerry Fraser Lambrick Park Secondary Teacher Victoria, BC, Canada
In Moodle 1.5 development code (not in 1.4.2 yet) is support for a new configuration parameter which you can set in config.php by adding:
$CFG->tracksessionip = true;
What it does is store the IP of the user when they first authenticate, and then checks for changes every time they access a page. If the IP changes then they get an error and are prevented from doing anything.
This doesn't solve the cause of the original problem (which is somewhere in PHP or caching etc) but it does prevent it being a problem within Moodle.
$CFG->tracksessionip = true;
What it does is store the IP of the user when they first authenticate, and then checks for changes every time they access a page. If the IP changes then they get an error and are prevented from doing anything.
This doesn't solve the cause of the original problem (which is somewhere in PHP or caching etc) but it does prevent it being a problem within Moodle.
Good test script, Petr! I've left this running on the server for several hours on the server I had trouble with originally, but unfortunately I couldn't get the problem to reoccur for me.
We must know how to replicate this error first, only then the problem can be solved.
Maybe there is some very specific moment when this happens:
We definitely need somebody to test this script on problematic server where this happens often. Maybe make a longer delay and do it when students are working.
I could also add some sort of password protection to make it possible to test it on production servers without the fear of DoS (from overloading the server). Then it could be in official distro if Martin thinks so. Or we could make some diagnostic package as optional download
Maybe there is some very specific moment when this happens:
- the URLs must be the same??
- new user must connect for the first time??
- there must be some special page parameters??
- ...??
We definitely need somebody to test this script on problematic server where this happens often. Maybe make a longer delay and do it when students are working.
I could also add some sort of password protection to make it possible to test it on production servers without the fear of DoS (from overloading the server). Then it could be in official distro if Martin thinks so. Or we could make some diagnostic package as optional download
Ok here goes...
I have exactly the same problem but not on moodle (i hope that is not a problem).
some more information:
I register several session variables after a user logs in:
if($login_check > 0){
while($row = mysql_fetch_array($sql)){
foreach( $row AS $key => $val ){
$$key = stripslashes( $val );
}
// Register some session variables!
session_register('user_id');
$_SESSION['user_id'] = $user_id;
session_register('first_name');
$_SESSION['first_name'] = $first_name;
session_register('last_name');
$_SESSION['last_name'] = $last_name;
session_register('user_level');
$_SESSION['user_level'] = $user_level;
Now when several users are logged in and do some actions, after an undefined time and undefined actions this happens:
the session variable user_id of user xxx suddenly changes to the session variable user_id of user yyy while the other variables stay correct.
This means there name and the other information is shown correctly while there user_id is not.
A conclusion till now:
There does not seem to be a repetetive way when this happens (not in time, not in actions, not in amount of users logged in)
Also, can these php.ini variables influence the way sessions are handled, and can this be a reason for this problem?
session.save_path (existing, writeable or not)
session.use_trans_sid (1 or 0)
register_globals (on or off)
thx in advance
Reinhart
Hi, I am new with this, but I have to manage some moodle´s in my new work and I´ve find that you have the same problem...
What I have to add to this situation is something that I think may help to think...
The person who use to work here installed a very susccesful moodle 1.4.1+ that is actually working fine. Then, when I came here, I have to install a second moodle (1.4.1) in the same server and this one do have the "user" problem.
I tried to copy all the configuration settings from the first to my moodle, but nothing change.
* So, how is possible tha the same Apache and PHP version works apropiately in the first case, and not it the other?
* Could be a configuration option? Someone suggest me to check the configuration of both databases... but I dont know how.
When I asked to the person who had installed the first one he told me that there was a third (and old) moodle installed in the same server. When I checked this one (1.3) I discovered that this has the weird problem too.
As the installation order was :
The 1.4.1+ (the one that work)
The 1.3
The 1.4.1
I ask: can I have more than one moodle in the same sever??
What I have to add to this situation is something that I think may help to think...
The person who use to work here installed a very susccesful moodle 1.4.1+ that is actually working fine. Then, when I came here, I have to install a second moodle (1.4.1) in the same server and this one do have the "user" problem.
I tried to copy all the configuration settings from the first to my moodle, but nothing change.
* So, how is possible tha the same Apache and PHP version works apropiately in the first case, and not it the other?
* Could be a configuration option? Someone suggest me to check the configuration of both databases... but I dont know how.
When I asked to the person who had installed the first one he told me that there was a third (and old) moodle installed in the same server. When I checked this one (1.3) I discovered that this has the weird problem too.
As the installation order was :
The 1.4.1+ (the one that work)
The 1.3
The 1.4.1
I ask: can I have more than one moodle in the same sever??
I think that I have some clues that one expert moodle administrator may use to fix our problem...
To completly understand what my situation is please take a look to my previous message before start reading this one.
I had told you that I have several moodles installed in the same server, and that one of then was working correctly, and the others didn´t. One of my partners made a course backup of a course of the bad moodle, and then restored it in the good one. The result was that the good moodle started to have problems too, but fortunately only with the people involved in the restored course. If I unsubscribe someone of this course everything goes rigth for him. Right now I am trying to delete this course and see what happens.
One of the tearchers that use my moodle told me that when he started to have problem he saw this messege that could be useful, but I dont know what does it mean :
Warning: Invalid argument supplied for foreach() in
/var/www/moodle/course/lib.php on line 377
This is part of my code, from line 375 to 381
if ($showgroups) {
$cgroups = get_groups($course->id);
foreach ($cgroups as $cgroup) {
$groups[$cgroup->id] = $cgroup->name;
}
choose_from_menu ($groups, "group", $selectedgroup,
get_string("allgroups") );
}
I dont know if there is a relation betwen this warning messege and the user authentication problem.
If some of you come up with an idea please contact me.
To completly understand what my situation is please take a look to my previous message before start reading this one.
I had told you that I have several moodles installed in the same server, and that one of then was working correctly, and the others didn´t. One of my partners made a course backup of a course of the bad moodle, and then restored it in the good one. The result was that the good moodle started to have problems too, but fortunately only with the people involved in the restored course. If I unsubscribe someone of this course everything goes rigth for him. Right now I am trying to delete this course and see what happens.
One of the tearchers that use my moodle told me that when he started to have problem he saw this messege that could be useful, but I dont know what does it mean :
Warning: Invalid argument supplied for foreach() in
/var/www/moodle/course/lib.php on line 377
This is part of my code, from line 375 to 381
if ($showgroups) {
$cgroups = get_groups($course->id);
foreach ($cgroups as $cgroup) {
$groups[$cgroup->id] = $cgroup->name;
}
choose_from_menu ($groups, "group", $selectedgroup,
get_string("allgroups") );
}
I dont know if there is a relation betwen this warning messege and the user authentication problem.
If some of you come up with an idea please contact me.
Hi there. I use mandrake 10.1 and have seen the same problem. It seems the problem can be seen only in mandrake 10.0 and 10.1.
I'm pretty positive most of the people that do not have the proper expertise (and thus installed mandrake - long live urpmi !) have been coping with this problem for a long time...
I'm pretty positive most of the people that do not have the proper expertise (and thus installed mandrake - long live urpmi !) have been coping with this problem for a long time...
unfortunatelly nο,
I have the same problem in Fedora Core 3
I have the same user id problems ONLY if more than 10 people from the same ip (via proxy) are trying to work in moodle...
I have the same problem in Fedora Core 3
I have the same user id problems ONLY if more than 10 people from the same ip (via proxy) are trying to work in moodle...