Jump to content

tkat

Approved members
  • Content Count

    67
  • Joined

  • Last visited

About tkat

  • Rank
    Member

Recent Profile Visitors

1,721 profile views
  1. Starting October 8 banners trafficked using DCM tags appear to be blocked if the {clickurl} macro is inserted in order to track clicks on Revive. With the clicktracker macro inserted, when the banner is clicked, it blocks the request at the Google redirect page, giving a "You don't have permission" error message on Chrome and just a blank page on Safari. Additionally the clicks are not logged by DCM. When the {clickurl} macro is removed from the banner tag, the banner can be trafficked through the Revive adserver and clicks through correctly. The apparent rationale for this c
  2. I really appreciate your taking time to respond. You're right that the problems aren't the same as it persists after I implemented your solution for your issue. Yes, the redirect for doubleclick was working fine until this issue popped up last last night. Please let me know if you find yourself encountering the same issues with Google.
  3. Hello IvorD, We are having the same problem, with our ad tags getting blocked by Google Ad Manager. We use our Revive adserver to distribute the 3rd-party ad tags (usually from DCM, sometimes from Sizmek) provided by our advertisers to our various affiliate publishers. The pubs generally use Google Ad Manager to serve our tags to their various zones. GAM is now blocking many of our tags when publishers try to enter them into GAM. Now when the ad does manage to get served via overlay tags which some pubs paste directly into their pages, bypassing GAM, and a user clicks the
  4. This article details how a hacker named Tag Barnakle has compromised dozens of Revive adservers by exploiting open redirects to compromise banner tags into sending users to malware pages: https://en.secnews.gr/221097/revive-ad-servers-tag-barnakle-diafimiseis/ When the adserver is compromised, banner tags may be blocked by Google Ad Manager, preventing publishers from delivering banners to that tag. Has a fix been made to prevent this problem from infecting a Revive install?
  5. Finally managed to get Revive ver 5.0.4 installed. But the GeoIP2 Plugin is baffling. The key for my paid GeoIP2 subscription was entered into the Plugin settings, but only the GeoLite-City database is being downloaded. Using SSH I see a version 2.0 of geoipupdate installed in the /bin folder. According to MaxMind support that old version isn't capable of download the GeoIP2 databases. Does the Revive GeoIP2 plugin install ver 2.0 of geoipupdate? Or do we need to separately install the GeoIP.conf and geoipupdate in order for the GeoIP2 plugin to function?
  6. I have made a number of attempts over the past 4 months to upgrade from ver. 4.1.4 to 5.0.x, the latest effort being a few minutes ago. I have successfully made over at least a half-dozen upgrades over the past decade and am familiar with the process. However, each time in my efforts at upgrading to ver 5x, at the final step I keep getting the error message: One or more plugin files can't be found. I have checked the install log and it says the xml files can't be located though the files appear to be there. This is the same error I have been getting consistently over the ma
  7. I had tried using the filepath /home/myacct/public_html/revive in earlier attempts with the same results. Tried it again but the sme problem finding the plugin XML files. Any other suggestions would be appreciated.
  8. Tried again with v. 5.0.1 after changing plugin-related folders in the old install to 777. Upgrade wizard throws off the same error message about being unable to locate one or more plugins. But the debug log presents a different error messages focusing on the package definition files: Nov 01 23:34:54 +0000 OX-5dbcc11e2813c [ error] Failed to find package definition file https://mydomain.com/Revive/plugins/etc/openXAdvancedMobileTargeting.xml Nov 01 23:34:54 +0000 OX-5dbcc11e2813c [ error] Failed to find package definition file https://mydomain.com/Revive/plugins/
  9. Both the old and new installs are in the same server and domain. Also, I verified that the old install's var, plugins and www/admin/plugin folders are set to 777. However, the subfolders within the admin/plugins folder are all 755. Should those be 777? Also the old install's etc folder, which actually contains the plugin zip files, is 755. Should that be 777 as well? Thanks again!
  10. Thanks for your reply, Andrew. Permissions were set to 777 for the Plugins, Var and WWW/Admin/plugins folders. The Images folder had been created outside the Revive installation. We're upgrading from 4.14 to 5.0.0. During the upgrade process we are using the MultiPHP Manager to toggle between our current PHP 5.6 and PHP 7.2 versions. Any other suggestions you can provide as to what could cause this would be very much appreciated!
  11. Tried again with absolute addressing. It was still unable to locate XML files of any of the plugins: table prefix: rv_ successfully initialised DB Upgrade verifying/creating constructive tasklist Revive Adserver 4.1.4 detected This version can be upgraded Database settings and permissions are OK Starting file-check for plugins... Plugin: openXAdvancedMobileTargeting - Unable to locate XML files Plugin: openXBannerTypes - Unable to locate XML files Plugin: openXDeliveryLimitations - Unable to locate XML files Plugin: openX3rdPartyServers - Unable to locate XML files Plugin: openXReports - U
  12. The upgrade wizard keeps giving me the message: One or more plugin files couldn't be located, check the install.log file for more information When I check install logs it is unable to locate XML files for any of the installed and working plugins. I know the path to the current install is correct, so am baffled what to do at this point. And the paths the install log lists doesn't reflect the actual location of files as the "extensions" subdirectory is not one levelbelow the Revive installation: Plugin: openXBannerTypes - Unable to locate file: /home/xxx/public_html/Revive/extensi
  13. Did the Google Ad Manager indicate deloplen.com and prombanner.com among the malware domains infecting your tags? We had reports from a few of our publishers about the GAM malware block on our tags.
  14. Some publishers we work with are experiencing similar issues with Google Ad Manager. Was the tag blocked by DFP? Did DFP elaborate what the policy violation is? Did it involve alleged links to malware domains?
  15. Has anyone else had an ad tag blocked on GAM for being linked to the malvertising domain adsnetclick.com We've never worked with this domain but publishers are getting a "Blocked for Malvertising" message on GAM when they try to implement our tags. Is it possible that this malvertising network may have infiltrated our Revive install via some vulnerability to link its banners to Revive tags?
×
×
  • Create New...