Jump to content

scott001

Approved members
  • Content Count

    47
  • Joined

  • Last visited

About scott001

  • Rank
    Newbie

Recent Profile Visitors

897 profile views
  1. 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?
  2. scott001

    What Files, What Permissions

    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?
  3. This works fine, and perhaps should be the way the code is implemented?
  4. 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.
  5. Any help would be appreciated....I am surprised that this isn't an issue for more users.
  6. For some reason my dashboard is now a blank white page--only the header shows up. I see no errors in my logs. Any idea why?
  7. I use async tags like below to several ads per page. <!-- Advertising Asynchronous JS Tag - Generated with Revive Adserver v4.1.4 --> <ins data-revive-zoneid="325" data-revive-id="1231231236728d3123911a0123"></ins> <script async src="//www.mysite.com/adserv/www/delivery/asyncjs.php"></script> It works fine, however, on site speed tests I am now seeing warning like this: The following scripts are parsed and executed several times on your page: //www.wheat-free.com/adserv/www/delivery/asyncjs.php (parsed and executed 11 times) 1) I am aware of the single page call tag that I've used in the past to serve ads, but is it possible to use the single page call with the async tags? 2) A proposed solution that is used widely, is below, but I am not sure how to make this work for my site..any help would be appreciated. I'm not even sure, once this is written properly for my situation, where the script would go...the header? Here is their example for Facebook--I have bolded area that probably need to to be changed, but again, I am not sure: (function(d, s, id){ var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) {return;} js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/en_US/sdk.js"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk')); So to make this work for my ad script: //www.mysite.com/adserv/www/delivery/asyncjs.php it might look something like this: (function(d, s, id){ var js, mjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) {return;} js = d.createElement(s); js.id = id; js.src = "//www.mysite.com/adserv/www/delivery/asyncjs.php"; mjs.parentNode.insertBefore(js, mjs); }(document, 'script', 'mysite-jssdk'));
  8. scott001

    What Files, What Permissions

    Just FYI, here is how I've been doing this, and it stopped the errors, and I believe is a secure way to run for most apache users: chmod -R a+w /revive/var chmod -R 644 /revive/var/cache/*.php chmod -R 644 /revive/var/cache/*.php.meta 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/ PS - These should be run in order from top to bottom.
  9. scott001

    What Files, What Permissions

    Sorry to bring this up again, but I upgraded yesterday and ran into more permission issues. So the command that your software said I need to run before upgrading was: chmod -R a+w /public_html/revive/var This puts permission for everything in that directory at 666. The problem is that there are a few files in /var/cache that contain my database password info, like www.mysite.com_admin_container.php and localhost_admin_container.php. Do you agree that these probably should not be at 666? Changing these to 644 or 444 seems to trigger the warnings.
  10. Nice, thank you Andrew!!
  11. Maybe the solution is for me to turn on strict mode on my current mariadb 10.1 using what I learned here: https://www.liquidweb.com/kb/how-to-disable-mysql-strict-mode/ and see if everything goes ok? My concern is that bad things could start happening to the db without me noticing right away. I was really hoping that the developers on this software could help with this more...who else should know this besides them? MariaDB is now the standard, and mysql support will end soon.
  12. Any idea if strict mode in mysql is ok for Revive?
  13. Is Revive Adserver compatible with MariaDB 10.2 ? I am currently running MariaDB 10.1, and see this warning when I go to upgrade: MariaDB enables "strict mode" by default as of version 10.2. Strict mode controls how MariaDB and MySQL handle invalid or missing values in data-change statements such as INSERT or UPDATE. Applications not built with strict mode enabled may cause undesired behavior; please verify applications using MariaDB are compatible before upgrading. More information about strict mode is available here
  14. scott001

    What Files, What Permissions

    Also, I discovered more files that contain my site's login info, which should probably also have at least 644 permissions. So we know about the config file which should probably be 444: var/www.mysite.com.conf.php But also in /var/cache are the following which contain your site's login info/passwords, which probably should be at least 644, if not 444: var/cache/localhost_admin_container.php var/cache/www.mysite.com_admin_container.php.meta var/cache/localhost_admin_container.php.meta Don't forget this one mentioned earlier: var/cache/www.mysite.com_admin_container.php
  15. scott001

    What Files, What Permissions

    It's your software, why not just give the exact permissions we need to set with a publicly facing site??? I don't write your software, but as a user I need to know this. Your software is throwing errors--based on what? The site you send me to to fix those errors doesn't have the required information for me to fix those errors, yet you keep sending people there. PS - I would not set this file /var/cache/www.mydomin.com_admin_container.php to anything other than 644 or higher, perhaps even 444 if that would work. So why not just give your users the most conservative setting that will prevent the software from throwing the errors? That is all I am saying here. Why leave us to guess from dozens of possible permissions?
×