stapel_eliz

1) I (finally) got around to updating Revive from 2016's 5.0.4 to 2021's 5.3.0. I did the update through cPanel's Softaculous package. It did the update successfully, but didn't seem to *know* that it had done the update, as it reported that I was still running 5.0.4. When I asked it then to do the update again, it checked and then "noticed" (?) that the version was indeed 5.3.0. The "installation" date remained from 2016. Today, I used Softaculous (which was still showing the version as being 5.0.4) to update from 5.3.0 to 5.3.1. The update went through correctly, and Softaculous has updated the version to show 5.3.1. However, the install date from 2016 remains. Ideas? 2) When I log into Revive, I am immediately taken to the Admin's Configuration => Maintenance => Security page, where I find the following warning: Some directories in the Revive Adserver package are not supposed to be served by your webserver directly, for security reasons. Leaving such files and directories accessible might disclose unwanted information and pose a security threat. A quick security check has been run and you will find the results below. Your browser was able to fetch some files that should not be accessible. For example: var/INSTALLED var/cache/README.txt etc/database_action.xml plugins/etc/openXDeliveryLog.xml Click here to find more information on how to secure your installation. When I click on the "more information" link, I am taken to: * https://www.revive-adserver.com/how-to/secure-your-installation/ My Apache server *does* allow .htaccess files, so the above page kinda reads like I shouldn't need to do anything. But I tried adding the specified language anyway: <Directory /home/username/public_html/revive_directory> AllowOverride AuthConfig Limit </Directory> This immediately started generating loads of server errors. So I removed the language, and am now stuck with the Security "warnings". Another user has even tried deleting the README file, but still gets the error message about it. (See thread below.) In my case, the INSTALLED file is empty, so I fail to see what "risk" it could pose...? Are these files, and their possible accessibility, *really* an issue? If so, will somebody from Revive please provide a working fix, or at least reply with an explanation? Thank you! Eliz. Stapel

I am seeing the same error messages. My Apache server allows .htaccess files, so I shouldn't have needed to do anything, according to this page: * https://www.revive-adserver.com/how-to/secure-your-installation/ But, upon receiving the error messages within Revive, I added the "AllowOverride AuthConfig Limit" language to each of the .htaccess files. This causes loads of server errors immediately to be generated, so I removed the language. Revive's security notice then returned. Given the choice between (a) the server being unhappy and (b) Revive having quibbles, I'll chose the server every time. Since the files' non-existence (after you made your deletions) is not sufficient to "fix" the Security check within Revive, and since nobody here seems to have an answer, you may just have to tell your user that it's a known error, you hope it'll be fixed soon, and he can ignore it. Good luck! Eliz.

440music: I've looked in my configuration file, and I can't find any database-version information in it. michems: I had updated from 5.0.4 to 5.3.0 thru cPanel's Softaculous package, and it continued, after updating, to think I was running 5.0.4. But when I asked it to update (again), it "noticed" that I was really running 5.3.0. However, the date of installation remained from back in 2016. Today, I've updated from 5.3.0 to 5.3.1 thru Softaculous. The package now agrees that the version is 5.3.1; however, the installation date remains 2016. I have no idea how one might go about fixing this.

Did this work in 5.0.4, but now is broken in 5.0.5? Because it kinda looked like things were going okay earlier in 2020...?

I think there was a "solution" that didn't work, then then they did another solution that *did* work... if I'm understanding things correctly, and I could certainly be wrong. Here's the (possible) solution to the Google-Chrome-SameSite,issue:

Dang. When I saw your subject line in response to my search, I was hopeful of an answer, and possibly even a solution. I guess not, huh? If I figure anything out (a big "if", as I'm not that bright sometimes), I'll try to remember to post a follow-up here. ============================== Edit: Is this (below) maybe the answer we're looking for...?

Yes, I did. I've tried using US ZIP codes for the city in Florida, but still no joy. Also, there is only a *.lock file for the Cities database. Should I create ones for the ASN and Country databases, as well? Thank you! Eliz.

When I had no targeting rules for the banners, the ads did serve, according to the displayed statistics. With the targeting rules in place, nothing has served. Unfortunately, I can find next to no information on "correctly" setting up the targeting. (For instance, I had to figure out for myself that a longitude of "80 degrees W" should be formatted as "-80".) I am using Revive 5.0.4. I had to figure out how to install the MaxMind geo-targeting myself, since it did not install automatically. (There was nothing in the /var/plugins/rvMaxMindGeoIP2/ directory but a "*.lock" file.) According to the GitHub repository, the "plugins_repo" folder is specifically related to the MaxMind geo-targeting. Update: I have also tried using ZIP codes for the particular area, using "OR" connectors, and still no joy. Thank you! Eliz.

I've upgraded to version 5.0.4, and am attempting to use geo-targeting. I'm trying to use longitude and latitude for the targeting. I'm pretty sure I have set up the MaxMind ASN, City, and Country databases correctly (Revive shows the geo-targeting options as available.) However, using a proxy server, I cannot seem to get the geo-targeted ad to display, so I'm wondering if I actually have things set up correctly. When I look at GitHub and at various forum posts, I see that geo-targeting might need the "plugins_repo" directory. My installation doesn't have this. Advice? Thank you! Eliz.

Thank you!

The problem turned out to be that my server host hadn't actually updated PHP from version 5-point-somthing, despite my request that they do so (and assurances that they had). When Revive did the update (via cPanel's Softaculous), it asked if it could update the version of PHP but, though I'd said "yes", the update didn't apparently go through. The solution was to do the update myself. Thank you! Eliz.

When I log into my Revive dashboard, I can check the various advertiser accounts that have been set up. When I do so, I am able to view the linked zones and any delivery limitations. Today, I logged into a new advertiser account (on v4.2.1), and realized that the advertiser does not have access to this information. Is this how the client accounts are supposed to be, or have I messed something up? Thank you! Eliz.

Since updating my installation recently, I've been seeing error messages. According to the current installation (while in "Admin" mode): You are currently using Revive Adserver v4.2.1 running on Apache 2.4.39, PHP 7.0.33 and MySQL 5.6.44-. When I open an "inventory" account (in "manager" mode), I see the following message: MESSAGE: Declaration of OA_Admin_UI_Rule_Min::validate($value, $min) should be compatible with HTML_QuickForm_Rule::validate($value) TYPE: Warning FILE: /home/purple04/public_html/mathads/lib/OA/Admin/UI/component/rule/Min.php LINE: 41 DEBUG INFO: 36 function getValidationScript($options = null) 37 { 38 return array('', ""); //return nothing, we use JQuery validate anyway 39 } 40 41 } 42 ?> 43 44 45 46 According to the debug log (with the domain's server account being anonymized as "domain"): RV-5d4db179922a2 [ warning] Declaration of OA_Admin_UI_Rule_Min::validate($value, $min) should be compatible with HTML_QuickForm_Rule::validate($value) on line 113 of &quot;/home/domain/public_html/adserver/lib/max/ErrorHandler.php&quot; on line 125 of &quot;/home/domain/public_html/adserver/lib/pear/HTML/QuickForm/RuleRegistry.php&quot; on line 125 of &quot;/home/domain/public_html/adserver/lib/pear/HTML/QuickForm/RuleRegistry.php&quot; on line 174 of &quot;/home/domain/public_html/adserver/lib/pear/HTML/QuickForm/RuleRegistry.php&quot; on line 1797 of &quot;/home/domain/public_html/adserver/lib/pear/HTML/QuickForm.php&quot; on line 194 of &quot;/home/domain/public_html/adserver/lib/pear/HTML/QuickForm/Renderer/Array.php&quot; on line 40 of &quot;/home/domain/public_html/adserver/lib/OA/Admin/UI/component/ArrayRenderer.php&quot; on line 1675 of &quot;/home/domain/public_html/adserver/lib/pear/HTML/QuickForm.php&quot; on line 300 of &quot;/home/domain/public_html/adserver/lib/OA/Admin/UI/component/Form.php&quot; on line 307 of &quot;/home/domain/public_html/adserver/lib/OA/Admin/UI/component/Form.php&quot; on line 245 of &quot;/home/domain/public_html/adserver/www/admin/advertiser-edit.php&quot; on line 88 of &quot;/home/domain/public_html/adserver/www/admin/advertiser-edit.php&quot; The lines in the "warning" are always the same, but they're not occurring continuously, so not every ad impression is generating errors... I think... Any ideas? I don't know if it matters, but I did the update via cPanel's "Softaculous" utility. And ads are indeed being served and logged. Thank you! Eliz. Edit: In poking around GitHub, I see that many files were updated "14 days ago". Does this mean there is a newer version of Revive? https://github.com/revive-adserver/revive-adserver

Okay. Interesting. How would uploading (and thus overwriting) only the updated files cause all the statistics to disappear, and no new statistics to be collected? Thank you! Eliz.

I know that the proper process for updating a Revive Adserver installation is NOT merely to upload whatever are the files with more-recent "save" dates. But why will this not work? (I understand that this is probably a painfully stupid question, but I'm... well... not always terribly bright.) Thank you! Eliz.