Jump to content

scott001

Approved members
  • Content Count

    68
  • Joined

  • Last visited

Everything posted by scott001

  1. I still have not tried to upgrade again. If you have made no changes to the 5.0 release, the same thing will happen, and I won't be able to upgrade. Were there any changes made to the software since I had this issue?
  2. I spent a day trying again to get a sub-domain working. I was able to get it working using the iFrame and Java tags, including the single page call Java tags, however, now matter what I did, I could not get the async tags working using the sub domain (which is my goal here). Is there any reason anyone can think of that would explain why all of the other tags are working for this, but not the async tags?
  3. PS - I did follow your upgrade process perfectly, copied over the new files, etc. I've been running this for over 10 years now, so know how to upgrade. I think you have a bug in your updater this time. I reverted my copy back to 4.2.1.
  4. I just upgraded to 5.0, ran the upgrade wizard, all seemed to go fine, but was expecting after it ran that when I went to my acp I would be prompted to update my database...I was not. When I go now to the Product Updates area I see: You are currently using Revive Adserver v5.0.0 (warning: database is stamped as v4.2.1) running on Apache, PHP 7.3.10 and MySQL 5.5.5-10.3.18-MariaDB. So was my database supposed to upgrade with 5.0? Now that it didn't happen, how can I upgrade it?
  5. Thank you for taking a shot at this, but it is configured correctly, as I am using it to serve images from another app that I run, which is my Invision Power Board forum.
  6. I've been trying to switch my installation of revive adserver (I'm v4.2.1 ) to serve ads to my site via a subdomain, instead of the main domain, but am having no luck. My main installation is at: www.mydomain.com/adserv and my current config has this for delivery: [webpath] admin="www.mydomain.com/adserv/www/admin" delivery="www.mydomain.com/adserv/www/delivery" deliverySSL="www.mydomain.com/adserv/www/delivery" images="www.mydomain.com/adserv/www/images" imagesSSL="www.mydomain.com/adserv/www/images" I use async tags, and I have updated the paths everywhere, including in cached and copies of config that are created, to be: [webpath] admin="www.mydomain.com/adserv/www/admin" delivery="ads.mydomain.com/adserv/www/delivery" deliverySSL="ads.mydomain.com/adserv/www/delivery" images="ads.mydomain.com/adserv/www/images" imagesSSL="ads.mydomain.com/adserv/www/images" I wanted to leave my admin access to be untouched, so I left that path the same. I change the async ad tag to the new location: <script async src="https://ads.mydomain.com/adserv/www/delivery/asyncjs.php" rel="preload" as="text/php"></script> and again, I used grep to find all instances of the paths, including: var/www.mydomain.com.conf.php var/cache/localhost_admin_container.php var/cache/mydomain.com_admin_container.php.meta var/cache/www.mydomain.com_admin_container.php var/cache/localhost_admin_container.php.meta var/cache/www.mydomain.com_admin_container.php.meta But I can't get the ads to display. Any ideas? Oh, and for a long time I can't get my debug error log working...it just puts in a strange character and is blank.
  7. I am still hoping for a solution to my insecure cookie issue. Revive is the only app on my domain that has this issue. All other apps have secure cookies.
  8. Is there a setting to make my cookies secure, as currently they are not secure: The following Cookies are not secure, you should add the Secure instruction in the Set-Cookie HTTP header: www.celiac.com/adserv/www/delivery/lg.php?banner[...]celiacs%2F&cb=f3814766b9 set-cookie: spcsrf=58357e9856fb6e2fa93de7f9cdfc37e6; Expires=Thu, 02-May-19 23:52:50 GMT; Path=/; HttpOnly; SameSite=Strict set-cookie: UTGv2=D-h4c33fdc6d399b6de8496e40aa580775b642; Expires=Fri, 01-May-20 21:52:50 GMT; Path=/ https://www.celiac.com/adserv/www/delivery/asyncjs.php set-cookie: spcsrf=6520eb79b20bf2806ff4d56baf063477; Expires=Thu, 02-May-19 23:52:48 GMT; Path=/; HttpOnly; SameSite=Strict set-cookie: UTGv2=D-h42c4ac14766f5128084800ade37ed3e0344; Expires=Fri, 01-May-20 21:52:48 GMT; Path=/
  9. I don't have my domain in the conf cookie setting...does this matter? If I add it should I include www? [openads] installed=1 requireSSL=1 sslPort=443 language=en [max] requireSSL=1 sslPort=443 [database] type=mysqli host=localhost port=3306 [cookie] permCookieSeconds=31536000 maxCookieSize=2048 domain= viewerIdDomain=
  10. I am still getting these warnings. The adserver's cookies are not secure https: The Secure directive By adding the Secure instruction in the Set-Cookie HTTP header, the server informs the browser that it is allowed to transmit the cookie over secure connection only. Read this blog post to learn more. Caution: Ensure that the HTTP to HTTPS redirect is activated on your website. Otherwise, the Secure cookie may not be sent on HTTP request. The following Cookies are not secure, you should add the Secure instruction in the Set-Cookie HTTP header: EXAMPLES: set-cookie: spcsrf=a7926253af246ee7f09f04062fcde42d; Expires=Thu, 25-Apr-19 19:03:00 GMT; Path=/; HttpOnly; SameSite=Strict set-cookie: UTGv2=D-h4f4bae1c99aeac150608db7df7d860a3547; Expires=Fri, 24-Apr-20 17:03:00 GMT; Path=/ set-cookie: OAID=a32d8dd64ecb4a95ef3092870b2080ea; expires=Fri, 24-Apr-2020 17:03:00 GMT; Max-Age=31536000; path=/ set-cookie: _OXLIA[2202]=pqj0p0-326; expires=Sat, 25-May-2019 17:03:00 GMT; Max-Age=2592000; path=/ Anyone know how to fix this? The answer probably lies in this file: lib/pear/HTTP/Request.php
  11. The only way to reproduce is to view the email that is sent out when a campaign is expiring. In my case the email from address is now malformed...not sure why, but it started after a recent upgrade. Again, all other system emails seem fine.
  12. I'm not sure how...every other email sent from my adserver system is normal, and follows the settings in the configuration file. The only email that has this issue is the impending ad expiration notice. I suspect there is a bug. PS - I am using sendmail and not php to send the emails.
  13. So the only further info I have is that it is possible that a 3rd party network that I was serving ads from served malware that somehow allowed them to inject those files. The strange thing was that they were indeed dated to the exact time and date as the rest of the installation files. I do always upgrade from Revive, and follow the link in admin to the upgrade file download. One think I wanted to point out, which could be a vulnerability, and I've pointed this out before, there are copies of the php config files in /var/cache which contain the password data. If you try to protect these files by chmoding them 644 you will get warning that your permissions are set incorrectly, and your ad stats may not be properly counted. The only way to stop the error, and the recommended permissions when running an installation where those directories are set to higher permissions, is to chmod them to 666. I am not sure this is secure enough. In any case, I did track the malware ads as coming from the 3rd party network, but I also discovered some injected hidden link to an Italian shopping site that was put into all pages of my site. Once I removed the two files mentioned that I found in the images directory the hidden links in my site ended. So I suspect that the malware ads that were served were somehow able to pull in the 2 files to the image directory. There needs to be an .htaccess file in that directory that stops php files from executing.
  14. Since I upgraded to v3.4.0 the system email "Impending campaign expiration" is now sending from my server name domain, and from "s". For example: From: "s" <s@scott.serverdomain.com> I've checked the config file and do not see anything that could cause this, and have no idea where the "s" is coming from. The email should be from "noreply@sitedomain.com"
  15. One of the Ad Networks that I used to serve ads from is called District M. Through them, unfortunately, I was also serving ads that contained horrible pop up malware...the type of ad pop up that you can't close or use the back button on--Usually claiming that you won a prize or that your device is infected and you simply need to download their "fix" to resolve it. I am wondering if it is possible that this type of malware could have also been the source of the 2 backdoor files? Could this malware also have utilized a Revive Adserver exploit to get the two files onto my site? I am surprised that more Revive folks have not responded here, as I do believe that there should be more concern about whatever exploit is being used to infect Revive installations. I've been using this software for over 10 years since it was called PHPAdsNew, and have never had such issues before.
  16. So I disinfected my site...these two files, according to Comodo, were back door scripts. Both were in my site's /www/images directory, so everyone may want to check their installation as well. The most disturbing thing is that one had the same date/time stamp on it as the Revive Adserver files 5/24/18 @ 3:49 AM. Is it possible that hackers somehow added this file to Revive's installation zip file before I downloaded it? I am just speculating here, but I am not sure how else that file could have the same date/time stamp as my other files.
  17. Thank you for this! I will report what I find here. So that grep command did not work because the files I found are somehow encrypted. For example, here is a small part of it: <?php $ijdskjfk["&@#13^3^4^%&3$*136223%(&3&%3%14**2&@$#&*6^#^^$&1(_22%!^=@%^+#@^&##@3##333#2$^3-3&$$3(323^^2&3)15&&5$57*)%)^53%&2#226&^%%%1##4^-^=4&43&^@#4=^%-3*3"]="\x32@\x25%\x25@\x5e%\x35^\x5e5\x32)\x25+\x3f5\x325\x34*\x31*\x5e1\x32&$
  18. I am running the latest version of Revive Adserver and am experiencing what I believe to be XSS code injection issues. I believe there could be a vulnerability/exploit out there. I've been running PHPAdsNew/OpenX/Revive for over 10 years and haven't had this happen before. I've checked for extra admin accounts and there are none, I changed my passwords, etc., but basically any ads I display cause a malware pop-up that you can't close followed by virus warnings. Also, I found files that were likely injected into my images folder...the contents were php but coded so they could not be read: ef245a0187359c78f346589bb7628562.php 45a0187359c78f346589bb7628562.php Any ideas out there on how to deal with it? I could use some help! Thank you!
  19. Ultimately I fixed this, and it was caused, apparently, by an advertiser that I created years ago. Re-creating the advertiser and ads solved the issue.
  20. After updating to the latest version of Revive Adserver v4.1.4 from version 4.1.1, I am having some issues with campaigns not balancing correctly. I have a group of banner zones which only two advertisers share, so each campaign is set at 50 weight, and when I look at each banner zone's Probability they correctly show 50% to each advertiser. However, the actual impressions that are displayed favor one advertiser ~80% to 20%. I've checked everything and can't find a reason for this. Any ideas? Also I am seeing this refused to connect. on my dashboard--the dashboard hasn't worked for quite some time...is this normal? If not, any guidance on fixing it?
  21. My site is a secure https site, and when I run tests on it the cookies that Revive Ad Server sets are non-https, insecure cookies. Is there a way that I can force the cookies to be https?
  22. Sorry to flog a dead horse, but the permissions above still create issues. So these make all errors go away, and seem to be the default setting for most people (just in case, a+w = 666): chmod -R a+w /revive/var chmod -R 444 /revive/var/www.my-domain.com.conf.php chmod -R a+w /revive/var/plugins/ chmod -R a+w /revive/var/templates_compiled/ chmod -R a+w /revive/www/images/ chmod -R a+w /revive/´╗┐www/admin/plugins/ However, when I protect the files below, some of which contain passwords to my database, the software throws the permission warnings. chmod -R 644 /revive/var/cache/*.php chmod -R 644 /revive/var/cache/*.php.meta What is your view on these files? Should they not be protected better, given that they contain sensitive info?
  23. This works fine, and perhaps should be the way the code is implemented?
  24. Here is what I've done, and I hope my banner stats will still be correct. I removed this tag throughout my entire site in my async ad code. This code appeared with each banner call, and in my case this meant 7 or more times per page load: <script async src="/adserv/www/delivery/asyncjs.php"></script> at the bottom of my site's global template, just before the closing </body> tag, I added this, and notice the "defer" in it: <script async src="/adserv/www/delivery/asyncjs.php" defer></script> I am testing it now, and hope the stats, click tracking, etc. will work. I will report my findings here. Doing this has done several things for my site speed, for example these scripts were causing a render blocking javascript issue on google's page speed tests, which has gone away now. Since the script is only loaded once, it speeds up the loading of each page.
×
×
  • Create New...