Matteo Beccati
-
Posts
269 -
Joined
-
Last visited
Posts posted by Matteo Beccati
-
-
What kind of invocation are you using?
-
As everyone else is saying, you're not giving the browser a chance to load the impression tracking pixel that is sent along with the meta tag. I'd suggest increasing the timeout to e.g. 3 seconds and also displaying something like "Redirecting..."
-
I had a look at the site and I'm sorry to say that you might not using the right tool for the job. A custom application or wordpress/drupal/etc module would probably serve your purpose better than a proper adserver can do.
That said, try to disable the cookie based fatures (e.g. delivery capping/blocking) and see if that helps.
-
I'm afraid the developer documentation is gone during the project move to Revive Adserver. So there's no relevant URLs to link to just yet.
-
If you see strict standards error messages there's something wrong with your setup, as they should be hidden.
Also, judging by the output above an extension (xdebug?) is messing up with error messages.
Finally, RevMax is a 3rd party product and you shouldn't be searching for support about it here
-
-
-
For reference, this has been fixed in 3.1.0.
-
For reference, this has been fixed in 3.1.0.
-
If you comment this line out, you might be able to run:
ant minify-delivery
which copies the files from www/delivery_dev to www/delivery, minifying them with YUI compressor.
-
Stay tuned
-
Thanks for the report. It is a known issue, since many years actually. The problem is that the oadest parameter is required for certain functionalities to work, and to this day no solution has been found that allows it while making it safer. I have spent myself numerous hours on it but I couldn't come up with anything good enough.
If you have a working solution, we'd be happy to review it and apply it.
-
Upgrade from phpAdsNew should be working from 2.0.11. If you're running 2.0.7, you might first need to upgrade to 2.0.11-pr1. I would suggest doing that with an old enough version of PHP (on a staging server, possibly). From there, it should be possible to upgrade directly to the latest Revive, but to be honest I haven't tested that in a while.
-
Your PHP setup might not allow Revive to redifine the include path. Maybe set_include_path is disabled via your php.ini?
-
This might be related to required functions being disabled, e.g. parse_ini_file.
Please replace your pre-check.php file with the one available here and you might see a nice error screen instead of all those error messages.
-
@al_bullit Did you apply both the patch files? DId you properly recompile/upgrade your packages and restart the webserver/php-fpm? If so, I'm afraid I don't know what else to suggest.
@msellers Whatever works for you. If you're able to fix the adserver and influence garbage collection so that it doesn't trigger the GC bug, I'll be very happy to apply your changes and lift the ban for the PHP versions affected by such bug.
-
Some blank pages (PHP segfaulting) is the result of the bug. Please make sure to apply both the commits related to the bug made by laruence (going from memory here).
-
Hi Mark,
thanks for the report. To be honest I wasn't aware of it as my knowledge of RPM-based distros is quite limited. I made a search a while ago and I thought that RHEL/Centos 7 had PHP 5.5 out of the box, which sadly isn't actually true.
The fact here is that, even if we wanted to, we can't make Revive Adserver compatible with PHP 5.4.16 as it is affected by a bug that causes segmentation faults when running it. Such bug has been fixed in PHP 5.5.2 and PHP 5.4.20.
Debian had the fix backported at some point to their Wheezy (going from memory) php package, but RedHat didn't yet. It would probably take some RH customer to submit a ticket for them to think about backporting the fix.
The only suggestion I have (thanks Remi) would be to use PHP 5.5 from RHSCL:
https://www.softwarecollections.org/en/scls/rhscl/php55/
I hope this helps.
-
-
"Temporary vs permanent" is only a trick that Revive uses to "pack" cookies in order to avoid hitting the limits on cookie number per domain. I.e. the content of a temporary cookie is appended to the permanent one on the next request.
-
You are correct in that the cookies related to delivery cappin are not set properly. I'm not sure how the Flash video player is involved in the process. I'm using JW Player 6.10 with ads.
(A) When I observed cookies in Firefox/Firebug it loads these:
_OACAP[1]
_OASCAP[1]
_OABLOCK[1]
_OACCAP[1]
_OACBLOCK[1]
_OAZCAP[1]
(
After first quartile those cookies just disappear without a trace to these cookies:OACAP
OASCAP
OABLOCK
OACCAP
OACBLOCK
OAZCAP
OAZBLOCK
Is this the intended behaviour? (Rhetoric question)
Yes, in theory. Cookies beginning with an underscore are "temporary" cookies that get merged to the permanent ones.
When I added this line
if(@$_REQUEST["vast_event])MAX_cookieFlush();//quick'n'dirty bug fix for frequency capping with video ad delivery
to www/delivery/fc.php after line 31 it happens so that cookie set (A) starts to "interact" with cookie set (
.Any insight on this?
Capping should be set when the impression is recorded, not when the request is made, so it is techincally wrong.
-
-
-
Hi Admin,
Im using JW6 Enterprise and looking for this plugin for my site, could you pls give me your plugin link? I did not see it on at adserverplugins.com ?
Thanks
I'm afraid it's not a free plugin, but we haven't been able to create a product page yet. Please use the contact form on the website if you are interested.
Open Url Redirect Vulnerability On Revive Adserver
in For Developers
Posted
I'm sorry, CSRF tokens have a very different purpose: session based, one-consumption-only tokens won't help for this use case.