All Activity

thank you for sharing your experience. let's hope it'll help someone in the future 🙂

New Install 5.5.2 Plesk Admin Panel Rocky 8 PHP 8.2 after update adding a new banner, I get a 403 Permission Denied page with a fresh install and adding Advertiser, User, or making any change I got a 403 error page I fixed this by changing the Mod_Security setting in Plesk Tools > Web Application Firewall changed the setting from ON to Directories Only

Response to CVE-2023-26756 We reject the assertion of a vulnerability in Revive Adserver, as is claimed in CVE-2023-26756. We are convinced our application offers sufficiently powerful tools against brute force attacks. We’ve posted a full response in the Security section of our website. Read more... The post Response to CVE-2023-26756 appeared first on Revive Adserver. [url={url}]View the full article[/url]

hi Saria, You might have seen it in the mean time, but here is a detailed blog about this topic https://www.revive-adserver.com/blog/how-does-revive-adserver-use-third-party-cookies/

Hi, I'm having a strange problem - the min.php is not loading any of the CSS or JS files for the UI. Only the widgets styles are loaded correctly. Everything else works; ads are being served correctly, but the UI styling is missing. When I open the link for the stylesheet/js it is simply empty. What I did so far: - I checked the server for errors - no PHP errors were reported for that issue/page. - I went in the directory (assets) and upped the permissions in the folder. - I checked "Force SSL" in the UI Preferences. That solved the "not secure" issue but not the styling one. I also tried it from the server itself. - I can see no relevant errors in the console. I'm a bit of a loss what else can I do/check. It's probably a permission / path issue, but I'm not sure where to look for it. Any ideas?

We just released Revive Adserver v5.5.2 This version ensures that MaxMind GeoLite2 City file downloads continue to work automatically after May 1st, 2024. It also contains some bug fixes and performance improvements. Changes in v5.5.2 of the Revive Adserver software: We updated the MaxMind GeoIP2 plugin to support the upcoming changes in the procedures required to download database updates from MaxMind. In order for the automatic updates to continue working, the MaxMind account ID needs to be added in the plugin configuration screen. We’ve updated the page that explains How to Configure MaxMind’s license key to download GeoIP2 files, please review and add your MaxMind account ID to the plugin’s settings before May 1st, 2024. We fixed the “Geo/Organisation” delivery rule that was not working as expected. We fixed and issue with the password recovery process showing an empty recovery screen at the end of a successful process, under some circumstances. We fixed an issue with midnight maintenance potentially becoming very slow during pruning of the data_summary_ad_zone_assoc table on big instances. We fixed the unexpected 500 errors when using an invalid configuration file. We fixed an issue with zone chaining being presented as a viable option for Email/Newsletter zones while it cannot actually work due to the limitations of such zone type (the click URL is hardcoded to the original zone ID). We fixed an issue with search settings being reset when typing a new search keyword. Compact view is also the new default in order to keep resource usage low. We fixed an issue with manager user delete permission not being properly checked when third party products were using the “DLL” data access layer. This issue was reported by the developers of the Revive Adserver REST API. Full release notes for v5.5.2 can be found on our Github page. Download, install and update Revive Adserver v5.5.2 is available for download now. Once downloaded, please refer to the instructions for Installations of Revive Adserver or for Updating Revive Adserver. Make sure that the server(s) being used meet(s) the minimum technical requirements. Community contributions The continued development of Revive Adserver is being sponsored by community members, either financially or in the form of code contributions, or by reporting issues they discovered while using the software. We’re very grateful for the support we’ve received. If you would like to contribute to our project, please consider becoming a patron on Patreon.com. Another way to contribute to our project, is by using the Revive Adserver Hosted edition. The post Revive Adserver v5.5.2 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

That`s great, hope you can figure it out. Take a look here if not already. https://revive-adserver.atlassian.net/wiki/spaces/DOCS/pages/721303/Tag+Settings

Hi isabella, thanks for the reply. The link to the page is https://www.vancouverislandcamping.net/male-and-female-clothing-size-conversion-charts/ but I believe I may have figured it out. It seems I was misunderstanding how the campaigns worked while reading through the docs. Went back and read them again. I also had to delete all my cached files in the "adserver/var/cache" folder as well as the browser cache in order to see it in action. Now I will continue to read the docs to see if there is a way to show different banners in the different zones on one page for each campaign instead of showing the same banner in all three zones every time the page refreshes. Appreciate your replies much appreciated.

Yes.

Found this error in my log does it have something to do with my issues? [11-Apr-2024 20:03:36 UTC] PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/myusername/public_html/adserver/lib/minify/JSMin.php on line 170

While my Revive VAST tags tested successfully using a VAST inspector, I can't get it to work on my Roku Apps? Is it incompatible or am I missing a setting? Anyone have any experience with this or have suggestions? Thank you. Test Inspector used: https://adplayer.pro/developer/vast_inspector

Sorry, what do you mean about sharing the link in private with the web page? Not exactly sure what you are telling me to do. I can provide a link to the live page in question if that is what you mean?

Can you share the link in private with the web page?

Well I tried adding the shortcode for the zone page1Top to the bottom and middle of the page and it shows my banners properly so I must be missing something with setting up zones or how to use multiple zones on one page. But for the life of me I cannot seem to figure out what I am doing wrong. Checked every log I can think of and there doesn't seem to be any security issues or errors. I'll keep looking for a solution until I find it or someone here is able to point me in the right direction.

I have the latest version of Revive Adserver installed on my dedicated server after upgrading from previous version everything went fine with the upgrade. I decided to try having more than one zone per page as more clients seem interested in my site. I created the zones and named them per page: example: page1Bottom, page2Bottom, page1Middle, page2Middle etc. I then added the zone generated invocation code into the appropriate wp custom code block like I did previously for my original zone (page1Top) that has worked for over 2 years just fine. I also placed the shortcode in the appropriate place on the page to call the invocation code. I created the client banners and client accounts than linked them to the new zone but even after 2 days the new zone isn't displaying the ads. My original zone is displaying them just fine. Walked through the troubleshooting docs provided from the Revive Adserver home page links but still not able to figure this out. Anyone else got multiple zones per page to work with wordpress? Also on a side note: I looked at your plugin for wordpress but it hasn't been updated in over 2 years so not sure it is the right choice either. https://www.adserverplugins.com/revive-adserver-in-your-cms/ I know I could use the existing widgets but then I cannot have different zones for individual pages. Thanks for your time.

Why are some people concerned about 3rd party cookies? Introduction In the first 2 articles in this series, we looked at what cookies are, and what the differences are between 1st party and 3rd party cookies, and we looked at how the Revive Adserver software uses both 1st party and 3rd party cookies. In this article, we’ll take a look at the reasons some people give for being concerned about 3rd party cookies. Quick recap of 3rd party cookies As a quick reminder, a third party cookie is created by a system or service on domain B, while it is being used within the context of a website on domain A. The website visitor on domain A sees the content of that site, but also some ‘embedded’ content of the service on domain B. That service could be anything, for example a weather report and forecast, stock market tickers, news headlines, and also advertising. Retargeting in advertising In particular around advertising, people have noticed that things can become a little bit spooky. Let’s assume for a moment that you’re looking to buy a new car. At some point, you visit the website of a car brand to view their lineup. An hour later, on a totally different site, doing something entirely different, you suddenly see ads for that specific car brand, and even the model you looked at. The next day, while visiting yet another site, again, you see these ads for the car brand once again. This could go on for days or even weeks. It almost feels like you’re being followed around the internet, and you can’t shake them off. What is actually happening is a marketing approach called retargeting, although Google (being Google) call it ‘remarketing’. Here’s how that works: The very moment you landed on the car brand website, an advertising system running in an external domain created a 3rd party cookie on your computer or phone, which records the assumed fact that you are interested in buying a new car. Later in the day, when you’re simply reading up on today’s events, the news website happens to be using that very same advertising system for their ads. As a result, the cookie about your car interest is sent along with the ad call. The advertising system has a campaign for the car brand available, and because of the presence of the cookie, some ads for these cars will be displayed on the news pages, instead of just a randomly selected ad for just about anything. The next day, you’re going over the sports news of the night before, and the sports website also uses that very same advertising system. The cookie is still present, and therefore you once again see ads for the car brand. Retargeting is big business Over the years, ad companies have become bigger and bigger, and a few of them dominate the entire advertising landscape. Their ads are literally everywhere. Every time your computer connects with a site or service that shows these ads, you’re likely to see these retargeted ads. If you don’t know about cookies, specifically 3rd party cookies, retargeting can quickly start to feel creepy, as if “they know how you are”. That is – of course – not true, all that’s happening is that the ad system is simply reacting to the presence of a cookie. They have no idea who you are, and for the most part they don’t even care. You once looked at a car website, and that’s interpreted as a signal that you are more likely to be in the market for a new car than somebody else who didn’t look at those cars. Blaming the cookie Over the years, a number of big ad tech companies went completely overboard with their retargeting activities. So much so, that it became a general annoyance to many people. At some point, the developers of Google Chrome – among others – decided that third party cookies were the cause of all these concerns. This is somewhat ironic, because Google has been making huge amounts of money with their retargeting practices all this time. But the scene was set. The third party cookie had to go. The problem is that there are many legitimate and harmless use cases for third party cookies that will be broken in the process (as outlined in the earlier articles in this series). In the meantime, Google (in particular) have been working hard to create their own systems and processes to replace the use of the third party cookie. Their ‘privacy sandbox’ initiative is one of them. And anyone who uses the web while logged in with a Google account is also still being tracked, even without third party cookies enabled. Just think about that time when you searched for something on your phone, and then suddenly saw an ad for that same product or service on your laptop, your tablet, and your desktop computer the next couple of days and weeks. No cookies were involved there, since after all cookies that are created on one device will never be present on any other device. So even after they’ve removed third party cookies completely, Google will still be able to track and retarget anyone with a Google account. What’s next in this series? In the next article in this series, we will be presenting an overview of the features of the Revive Adserver software that will be affected when the corresponding third party cookies are no longer available. Articles in this Series: What are Third Party Cookies? This article explains what a cookie is, and what the difference is between a first-party cookie and a third-party cookie. Read More How does Revive Adserver use Cookies? This article describes how first party and third party cookies are being used by the Revive Adserver software. Read More Why are some people concerned about 3rd party cookies? We discuss the extensive use of cookies for retargeting, causing them to be labeled harmful by some people. Read More The post Why are some people concerned about 3rd party cookies? appeared first on Revive Adserver. [url={url}]View the full article[/url]

Hi Team, I created an in-line ad in revive, is it possible to preroll it in an HTML5 audio tag?

Dear Friends I recently installed and configured Revive for the first time, the version is 5.5.1 But i am not able to see in-line video ad in the banner category. What should i do Naeem

Looking for someone that can do development/support on our instance of the ADS. Willing to pay a contractor. Please reach out and we can discuss.

With nginx it can be done by adding these location blocks: location = /delivery/asyncspc.php {fastcgi_hide_header Set-Cookie;} location = /delivery/lg.php {fastcgi_hide_header Set-Cookie;} Most likely you'd have to also repeat the php configuration (fastgi_pass etc.) inside each block. Also make sure that locations actually match your specific setup.

Is there anything new on the "NEVER deliver from the campaign"? I need this also.

I want to connenct with your DSP. actually i want to show advertise in my web so how could i do this.

How does Revive Adserver use third party cookies? Introduction In the first article in our series on cookies, we explained what a cookie is, followed by an explanation of the difference between first party cookies and third party cookies. This article follows up with a more detailed look at how the Revive Adserver software uses both types of cookies. Revive Adserver uses cookies in 2 areas The Revive Adserver software has 2 major components: The ad management user interface (also often referred to as the admin UI) The ad delivery scripts Each of them uses cookies, but each in a different way. In some cases, the cookies are by definition first party, and in other cases, depending on how the ad server is implemented on a website, the cookies are third party. First party cookies in the Revive Adserver admin UI There is literally just a single cookie involved in the admin UI. This cookie is used to record a session ID, and therefore it’s aptly named “sessionID”. It ensures that once a user logs in, and continues to work in the UI, they won’t have to provide their username and password every time they navigate to the next page. The session ID in itself is just a random value, completely meaningless, unique, and different for every new session. The same user can be logged in on multiple devices, and they’ll have a different session ID on each of the devices. The value of the session ID refers to a row in a table in the Revive Adserver database, and the details of the user’s session (like the timestamp of their last activity) are stored there. When the user logs out, the session ID is discarded, and the corresponding row in the database for the “old” session ID is also deleted. Then a new session ID is generated and stored in the same cookie, but since there is no corresponding database row (because the user is not logged in), it won’t let them access the user interface beyond the login form. In addition, this sessionID is stored in a “session cookie” which means it expires and gets deleted at the end of the user’s session, for example when they close their browser or shut down their computer. When a user logs in and then doesn’t interact with Revive Adserver for a prolonged period of time, the session becomes inactive and the user will have to log in again (resulting in a new session ID as well). And finally, it’s a first-party cookie, so it is not affected by the demise of 3rd party cookies. This particular cookie illustrates an extremely valuable use case for cookies: storing a value (in this case the session ID) so that it is available in the next interaction with the system. This is actually precisely what cookies were designed to do in the first place. How does Revive Adserver use third party cookies? Let’s set the stage for our explanation: Let’s assume that the Revive Adserver software was installed at this URL: “www.adserver.com”. Let’s also assume that the Revive Adserver system is being used to display ads on a website with a different domain, for example “www.website.com”. In this scenario, when you visit the website, and the website contains ads from the ad server, your web browser is dealing with two related but technically separate systems, the website and the ad server. Here is what happens while the ads are being retrieved and displayed: When people visit the site, their browser receives the content from www.website.com. That’s the primary system their browser interacts with. As part of the content of the site, their web browser will also receive one or more javascript code snippets for the actual ads, and these code snippets reference the ad server URL at www.adserver.com. So that’s a secondary system their browser is also interacting with. From the perspective of the browser, and the site it is interacting with, the ads are coming from an external source, so that’s why it’s called a third party. If the ad server tries to create a cookie, that cookie is technically associated with that external third party source, and therefore the cookie is also referred to as a third party cookie. A practical example of the benefits of a third party cookie We’d like to give a practical example of how the Revive Adserver software makes very good use of third party cookies. The software has a feature called geotargeting. It can be used by the ad server to determine if an ad should or should not be displayed for a site visitor, on the basis of their geographic location Let’s imagine that the aforementioned website is operating in North America, so the United States and Canada. One of their advertisers is a supermarket chain operating in Canada, which doesn’t have many reasons to display its ads to site viewers from the US. Geotargeting involves looking up the estimated geographical location of the site viewer in a large lookup table where the location assigned to groups of IP addresses is available. The outcome is a country code, and only if the country code is CA the ad will be displayed. While this is an extremely quick process, it does take a little time and some resources to do so. And this adds up if the ad server is serving many ads to many visitors simultaneously. In order to reduce the computing overhead of such lookups, the ad server can store the country code it found, in a cookie on the user’s device. In the setup we described earlier, where the website is on one domain, and the ad server is on another domain, that cookie containing the country code is technically a third party cookie. If geotargeting is used again later, perhaps for another advertiser, the visitor’s country code is already available in that cookie, so it won’t have to be looked up again. This saves the ad server some valuable time, which in turn improves the overall experience for the site viewer as well. Everybody wins! Why is third-party cookie blocking a problem? Once browsers start blocking the creation of these third party cookies, Revive Adserver won’t be able to store the country code it found for a particular visitor, and so it will need to perform the very same lookup of the IP address for every single interaction of that IP address with the ad server. The outcome is still the same, the ads can and will be targeted to people from the intended geographical locations. It’s just a less efficient process, increasing the costs of operating the ad server, and reducing the speed of rendering the ads on the site. Nobody wins anything, and in fact everybody loses something. Final thoughts This is just one example of how Revive Adserver uses third party cookies in a way that’s both entirely harmless and perfectly useful. There are other, similar use cases where bits of information are stored in cookies in order to make the ad server work more efficiently and faster for the site visitor. In the next article in this series, we’ll dive into the question of why some people are concerned about third party cookies, sparking the movement to get rid of them. We’ll also highlight how some companies are making good use of these concerns for their own benefit. The post How does Revive Adserver use third party cookies? appeared first on Revive Adserver. [url={url}]View the full article[/url]

hi Steve, When you test performance of asynchronous make sure to have ALL your zones using the asynchronous method. The reason is: The asynchronous method sends the actual zone invocation request on DOMContentLoaded. However the synchronous version delays this DOMContentLoaded event. This is also true when the async zone is before any sync zone (like seen in your screenshot) For example if on your PRD site you would add a single zone using asynchronous it would for synchronous zones to load which delay the yellow line (=DOMContentLoaded)

My hosted revive doesn't have a checkbox or a delete box and I can't find a means of deleting a banner from a campaign, am I missing something?