I'm using aMember Pro on a site where I'm ALSO using BoldChat to monitor what the heck my users are up to while they're on the site, and offer live tech support, blah blah blah. I have BoldChat setup to take the name_f field from amember_members and put it in my control panel - that part works flawlessly, so that as soon as a user logs in, I know which user it is and can track their movements. But a few minutes ago, one of my registered users logged in, looked at a couple of pages and left. There is NO RECORD of him in the aMember access log. It works SOMETIMES, because I logged on and I'm listed there. I know this user logged in, because the only way I get his user name in BoldChat is after he logs in through aMember. Is there a minimum amount of time a user has to be online before his info shows up? I'm worried now that a ton of users might have been on that I didn't know were there. Thanks.
Well of course there is such a thing. I'm using it, so it obviously exists. I'm using auto_prepend as security. The login works perfectly, the BoldChat application works perfectly. But in this one particular case, a user logged in and there was no record of him in the access log. The BoldChat monitor is a javascript that runs at the bottom of a PHP include file that contains my navigation menu (so it is on every page of my website). In that include, I have this: $login=$_SESSION['_amember_user']['login'] And if $login has a value, it is passed on to the BoldChat script which then adds that login to my BoldChat control panel. So the only way I get the user's name in my BoldChat control panel is if $login has a value. And unless I'm mistaken, the only way (from the above statement) that $login has a value, is if the user has logged in. And if a user logs in, I thought it was supposed to show up in the Access Log. In this one case, it didn't.
Okay, cool. Because it happens with this one user, repeatedly. He never shows up in the access logs, but I know he's logging on. None of my other users have this problem. Thanks for looking into it - any suggestions for a fix or a workaround?
It is not a bug to fix, it is a feature AOL proxy assigns a new IP for each request. This way IP locking will lock such users very quick and for nothing So I had to make this workaround.