jlow99

+Clients
  • Content count

    16
  • Joined

  • Last visited

About jlow99

  • Rank
    New Member

Recent Profile Visitors

1,021 profile views
  1. I think I'm experiencing the same thing Daniel F is reporting, I have experienced this twice when logging into an expired session with the login logs in view. This is what appears in the System Logs of IPS: "The log entry was triggered by a guest" Error: Call to a member function inGroup() on array (0) #0 /var/www/html/hvportal/init.php(442) : eval()'d code(26): IPS\loginlogs_hook_logs->log('GUEST', Array) #1 /var/www/html/hvportal/applications/core/modules/admin/system/login.php(52): IPS\loginlogs_hook_logs->authenticate() #2 /var/www/html/hvportal/system/Dispatcher/Controller.php(96): IPS\core\modules\admin\system\_login->manage() #3 /var/www/html/hvportal/system/Dispatcher/Dispatcher.php(129): IPS\Dispatcher\_Controller->execute() #4 /var/www/html/hvportal/admin/index.php(13): IPS\_Dispatcher->run() #5 {main} Backtrace: #0 /var/www/html/hvportal/init.php(506): IPS\_Log::log('Error: Call to ...', 'uncaught_except...') #1 [internal function]: IPS\IPS::exceptionHandler(Object(Error)) #2 {main}
  2. I did the upgrade from IP.Board 3.4.9 to 4.1.14.3 last night and can confirm that the old version v1.1 can be left as is through the upgrade. I did not deactivate or remove v1.1. Once the IPS4 was completed sorting itself out I installed v2 of the Login Logs by simply uploading the tar file and it took care of converting the data and removing it's old v1.1 remnant bits. This was nice to carry over the old data because I have login trends that are good to use for helping folks and backing up known issues or patterns of not remembering some types of credentials. I could have easily just removed the v1.1 instance prior to the upgrade but would have lost that history.
  3. Hello, I'd like to confirm what to do to keep the logs when upgrading from IP.Board 3.4 to IPS 4. I seems like I can just leave the Login Logs 1.1 installed on the IP.Board 3.4 instance and then after upgrading to IPS 4 I just simply install the new version of Login Logs 2.x? Is it really that easy? I don't have to remove the incompatible old version after or anything? My experience in the past with test upgrades from IP.Board 3.4 to 4.x is that it disables the v1.1 Log In Logs application. What I did was just remove the Login Logs application prior to upgrading to IPS V4. I can't recall but maybe there is a preserve data question but I can't remember prior to removing the app. Anyhow, I'm just hoping to see if the old app can be left during the upgrade of IPS to V4 and to simply install this v2.x of the Login Logs.
  4. When these patches come out I just create a copy (tar) file of my admin directory, just in case, and then extract the patch and then test. This patch works fine with 3.4.7 as I've just tested, but is intended for any 3.4.x as with other patches IPS have produced in the past.
  5. Hi bfarber Can you post a link please to this guide?
  6. I'd really like an optional setting to enable a "follow this topic" link to appear on email notifications of new topics. I'm not sure if the emailWrapper is the right place for it and should do some testing. I thought I'd ask regardless. It's great that the system can be set to send notifications of all new topics, but I need to take it a step further for really easy following capacity right within that notification. Does anyone know how to accomplish this? I was thinking of the the html emailwrapper in the manage system templates area. Would this be a feature request or something already accounted for in version 4? I guess the new topic link would have to be creativly caught as a variable for use in the email wrapper, I just don't know how it could be done automatically or if it's possible. Much Obliged, ~j
  7. Thanks Lindy, Kirito, AncientMariner!! AncientMariner's suggestion worked but I'm curious about what is more appropriate... open_basedir = /var/www/html:/usr/bin upload_tmp_dir = /tmp or open_basedir = /tmp:/var/www/html:/usr/bin Also, please confirm the /usr/bin definition there, I use ImageMagick as well for mediawiki but I'm not sure if /usr/bin leaves a vulnerability. I'll try it out in the next few days. One more thing, I hear about root kits installing themselves in /tmp so I'm also wondering about defining something other than /tmp, or are we stuck with that. I'm assuming we're stuck with /tmp and probably need something like selinux to protect the OS. I've gone way too far here. Thanks though for your help!
  8. This might be just me, but I've tested out setting open_basedir = /var/www/html (happens to be my web root default) with some negative side effects. The ability to upload files with ip.downloads or upload avatars seems to not work. Everything else seems to function which is good. Commenting open_basedir out again from my /etc/php.ini allows things to be uploaded again. Is this expected? The use of ip.downloads is pretty important to me and it would be nice if there is a work around for security sake. Note that I'm running on a physical host and have full control over the OS and files. I've tested this out with the latest and greatest version of IP.Board and IP.Downloads.