Jump to content

benwinton

Approved members
  • Content Count

    14
  • Joined

  • Last visited

Everything posted by benwinton

  1. Even after upgrading to Version 4.2.0, a hacker was able to use script injection to force his/her ads with the following Adsense ID -- pub-6084777151829107 -- into my websites. It appears this person found a way to get to a file named ads.txt, which is recommended by Google to allow specific Adsense IDs to be used on a website. The txt file is in the root directory of the site. I installed additional security software on both the webserver and via the Web host, and for the last 12 hours, things have settled down. I am not sure if the vulnerability is found in Adserver 4.2.0 or some other file in Wordpress. In any case, be on the lookout for this Adsense ID showing up on your site, especially if you notice Adsense revenues are down. I reported the ID to Google, but I never hear back from Google on anything I send to them.
  2. These are great instructions. Unfortunately, the ad clicks are not tracked through Revive, so there's no way to see how things are performing, unless you log into your Adsense account. Not a major issue, but it would be nice to see how the Adsense ads perform relative to all other ads on the same site.
  3. Just a security alert: After upgrading to Version 4.2.0 as quickly as possible, and following the upgrade procedures on the Revive website, my site still got hacked. How? Here is what I think happened: I followed the upgrade procedures found here, at this link, and these are excellent instructions, I would still follow: https://www.revive-adserver.com/support/upgrading/ But, I left my OLD backup files on the server. I had renamed the old directory to "bak" or something similar, to disable access to it. In spite of this, sometime in the 72 hours after the upgrade, the hackers mentioned in the security update notes, managed to exploit my Wordpress files and begin injecting their own ad code. As soon as I replaced the Wordpress files with my backup files, the hacked ads stopped appearing. Be on the lookout -- and remove any backup installs of your Adserver files asap, and the database, if it is a migrated or copied file. Thanks.
  4. Andrew, Thank you for the response. I might have found a workaround that has been successful for the last 48 hours: 1. Create a new ad zone and set the wildcards for the height and width -- "*". 2. Create a new Google Adsense banner and set its height and width to something arbitrary. I chose 800x133, because that seemed close to the proportions of their full-sized Native ad format. 3. Assign the new Adsense Native banner to the new ad zone that has the wildcards for its height and width. The Native ad format seems to be getting displayed and tracked properly on some test pages I created. Just a workaround. Maybe in a future release, Revive might have an even greater solution. :) Thanks!
  5. Not too long ago, Google introduced "Native ads" that can respond to the content AND the device around them to provide a more streamlined user experience between content and advertising on the website. However, I am not finding an easy way to integrate the code into the latest version of Revive Adserver. If I select Generic HTML as the format, I am forced to specify an IAB ad-unit size, which entirely defeats the purpose of "Native ads." Native ads change shape and size automatically, to adjust to the device and to the content around them. It's sort of like a responsive ad, but even more so -- maybe a responsive ad on steroids. How do you integrate AdSense's new Native ad format into the most current version of Revive Adserver?
  6. Thanks, Andrew. That is what I was thinking, and it helps to verify all is working as expected.
  7. For Andrew: My conf file is set to 644, but I still receive the warning -- as well -- for Version 4.1.1. Is there a way to remove the warning, and still have the permission on that file set to 644, or are we just stick with having to ignore the warning message? Sorry, I forgot to turn on the "notify me" feature of this forum. Just did that.
  8. Agreed! This is truly a bug, and it should be treated as such over at Github! Let's report the bug a second time to the developers and see if they "get it" this time. If not, and they close it again, we'll re-open it. If that fails, we can always let the world know that the support for the open source has degraded substantially since Version 3.0.3. and warn the public to be wary of further upgrades! One way to get developers to pay attention is to start letting the world know that they are NOT paying attention to their customers.
  9. Glad my solution (workaround) is successful. The directory at /adserver/maintenance (replace "adserver" with the name of your top-level revive directory), should be at least 755. (However, I set mine at 777 during testing to verify no issues with permissions.) Also, the directory at /adserver/scripts/maintenance should be at least 755. That should do it, and allow maintenance to run, which in turn affects statistics.
  10. I resolved mine by doing the following: 1. Locate the RV.php file. It should be at /lib directory of your revive installation. 2. Edit line 13 as follows: Change the line from this -- "require_once RV_PATH . '/lib/pear/PEAR.php';" to this, instead: require_once 'fully_qualified_server_path/adservername/lib/pear/PEAR.php'; ("fully_qualified_server_path" would be your host or webserver path. "adservername" is the name of your directory where revive 3.0.3. is installed, typically something like "revive.") Also check that your maintenance scripts are chmod'd to at least 755. I set mine to 777 for now, but am experimenting with lowering them back to 755.
  11. I found a solution. In the /lib file, there is a new file named RV.php that does not seemed to have existed before version 3.0.3 of Revive. The path to PEAR.php file on line 13 is coded up incorrectly. You have to put the fully qualified server path to PEAR.php in that file, eg, "require_once '/homepages/16/e34564563465/htdocs/ads/revive/lib/pear/PEAR.php'; (This is a fictional path above, for security reasons, but illustrates what the line should look like when fixed. I did not try using a fully qualified domain URL, eg, http://somedomain.com/revive/lib/pear/PEAR.php, but that might also be worth a shot to see if it works. I doubt that it will.) The only other thing I did was chmod the maintenance scripts from 755 to 777. I dont like doing that, and might try lowering them back to 755 to see if stats and automatic maintenance continues to run. Hoping this gets fixed over at GitHub, where there is a bug reported on this item, as well.
  12. Still having a problem. Followed all the suggestions listed, so far, in this thread, to no avail.
  13. Thank you Snoork Hosting for the response. I meant to write that there are no NEW statistics. The previous statistics remained frozen at the same numbers that existed at the same time as the upgrade occurred.
  14. I am continuing to have the same problem -- no statistics generated -- since upgrading to 3.0.3. I reinstalled all plugins in the following manner: 1. Disabled all plugins via the Admin Panel. 2. Uninstalled all plugins via the same panel. 3. FTP'd to the webserver and deleted all plugin folders. 4. Via the Admin Panel in Revive, I reinstalled all plugins by browsing to the /etc directory and selecting each zip file. (I used the new download for Revive 3.0.3. to ensure I had the latest plugin versions.) 5. Set my config file to chmod 777 and checked all settings. Did not change any settings. All looked good. So, I re-set the permissions on the config file (in the /var directory) to 644. Waited 1 hour. Still no new statistics. This problem first happened after the upgrade to the latest Revive version. The upgrade was done by following up the upgrade instructions.
×
×
  • Create New...