Revive Adserver Forum

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]

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]

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]

What Are Third Party Cookies? Introduction Much has been said already about the efforts by Google (and other manufacturers and software companies) to get rid of third-party cookies. However, not everyone actually knows what cookies are, and why there’s so much emphasis on their presumed “negative” effects. In a future article, we will describe in more detail how the Revive Adserver software uses cookies. We’ll also explain what the technical consequences are for users of Revive Adserver when third-party cookies get blocked. But in this article we will start by explaining what cookies are, and what the difference is between a first-party cookie and a third-party cookie. What is a cookie? Cookies are small pieces of data stored on a user’s device by websites. They help websites remember information about a user’s visit, such as their preference for light or dark mode, or their location to be used for the weather forecast. A cookie is not a program, it doesn’t do anything by itself. It is just a bit of data, and it just sits on your device, waiting to be read in the future. Frequently, cookies also have an expiration date, meaning that after the expiration date they will automatically be removed. Some cookies are even “session based”, meaning that as soon as you close your web browser or shut down your computer, they automatically disappear. What is a first-party cookie? Imagine placing an order at your favorite coffee place. After completing your order, the barista hands you a button to be worn on your clothing. It mentions your favorite coffee flavor, to save you the trouble of mentioning it again next time you go for coffee. Next time you come in, the barista can just take a quick look at the button, so they already know what your preferences are, and prepare your favorite coffee before you even get to a seat. For this imaginary button, it is important to mention that only the barista in that one coffee place can see and read the button. In any other store or shop, it is simply invisible, for all intents and purposes it does not exist. That’s similar to a first-party cookie. It’s a piece of information stored on your own device by a website you’re visiting. This cookie helps the website remember things like your preferred language settings, dark of light mode, and so on. It’s specific to that website and doesn’t share information with anyone else. It is stored on your own device, it doesn’t actually leave any trace on the site’s server at all. So, the next time you visit, the website already recognizes you because your device shows up with the cookie and the data in it, and then personalizes your experience based on your known preferences, just like remembering your favorite flavor in your coffee place. What is a third-party cookie? Now, imagine that another business, like a dry cleaning service, has an employee stationed at the coffee place. You can drop off your dry cleaning with them, and you can pick it up again once it’s ready. The dry cleaning employee can also hand you a button, this time with a discount code on it for future cleaning services. If you come back to the coffee place in the future, with a new item to be dry cleaned, the staffer can glance at the button and know that you qualify for the discount. And on top of that, if you ever enter any other store where the same dry cleaning service is also present, those staffers can also see your button and give you the discount. The button can only be seen and read by dry cleaning staff, nobody else will even see it, not the coffee store and none of the other customers there. Most likely, the dry cleaner won’t even know where you first received your button. This is similar to a third-party cookie. It’s created by a site or service that’s different from the website that you’re actually visiting. For example, while browsing a news website, an external weather service might set a cookie to store the geographic location you’ve specified. This allows them to display the weather information for your town when you visit the news site again in the future. Unlike a first-party cookie, this third-party cookie is not specific to the news website. If the same weather service is used on other sites, your location is already noted and you will see weather information for your location automatically on those other sites as well. Final notes These are not perfect analogies, by the way, because a cookie is only available on that one specific device where it was first created. Imagine you have a laptop and a tablet. A cookie that gets created on your laptop does not exist on your tablet, nor the other way around. That’s true for both first-party and third-party cookies. In the next article in this series, we will give you some examples of how the Revive Adserver software uses first-party cookies, and how it uses third-party cookies. The post What Are Third Party Cookies? appeared first on Revive Adserver. [url={url}]View the full article[/url]

We just released Revive Adserver v5.5.1 The new version 5.5.1 of the Revive Adserver software contains fixes for a number of small bugs and inconveniences that have been identified after publication of v5.5.0. Changes in v5.5.1 of the Revive Adserver software: We fixed an issue preventing username and password from being always requested during upgrades from 5.3.x and older versions. Running an upgrade with an active logged-in session on the browser could result in the admin account requiring a password reset at the next login. We fixed an issue with non-ASCII (e.g. accented) characters not being properly encoded when sending e-mails. We fixed an issue with the CLI installer not setting permissions properly. We removed legacy checks for register_argc_argv being enabled. In fact it is recommended to keep it disabled ony SAPI, other than “cli”, for security reasons. We removed references to safe_mode, which has been removed from PHP a long ago. We fixed a fatal TypeError being triggered during delivery under some circumstances. We fixed a potential out of memory error during maintenance in case of database issues. We added proper escaping when displaying custom application name and UI colour settings. Full release notes for v5.5.1 can be found on our Github page. Download, install and upgrade Revive Adserver v5.5.1 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. 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.1 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Future of the Revive Adserver open source project with Aqua Platform Following the announcement of Andrew Hill’s departure from the Revive Adserver open source project, and the subsequent announcement of the transfer of the Revive Adserver open source project to Aqua Platform, here are some remarks by the joint teams about the future of Revive Adserver. Addressing Community Concerns Understanding that such a transfer might raise concerns within the community, the teams involved in this process want to assure users and contributors that this move is driven entirely by a shared commitment to the project’s sustained success. The consolidation of activities into Aqua Platform is not a departure from community-driven open source principles, but rather a strategic move to ensure the project’s long-term viability. A History of Collaborative Success It’s crucial to acknowledge the longstanding collaboration between Aqua Platform and the Revive Adserver project. Aqua Platform has been a dedicated contributor to the project for many years, providing valuable insights and enhancements. Their involvement has extended to operating the entire backend of the Revive Adserver Hosted edition since its inception in 2018. Over time, an increasing overlap of activities and team composition has unfolded, triggering a discussion about the joint future, and ultimately leading to the agreement to consolidate all project activities under Aqua Platform’s purview. Continued Focus on Development and Maintenance Software development is a complex and resource-intensive endeavor. The transition to Aqua Platform ensures a prolonged stable financial foundation, mitigating the challenges associated with sustaining ongoing development efforts. This move underscores a commitment to the longevity and vibrancy of the Revive Adserver project. Aqua Platform’s Invaluable Expertise As a hosting company with hands-on experience managing enterprise-scale Revive Adserver installations since 2015, and founders that have been part of the community for 2 decades, Aqua Platform has been injecting a wealth of knowledge and expertise into the project. This firsthand understanding of the software’s intricacies positions Aqua Platform as an ideal steward for the continued growth and improvement of the Download edition. Financial Sustainability for Development Recognizing the financial demands of software development, the support from Patreon sponsors will be exclusively directed towards funding the ongoing development of the software. Aqua Platform will cover the remaining costs, in part from the revenues generated with Revive Adserver Hosted edition, and the rest coming from Aqua Platform’s own business activities. This collaborative approach ensures a sustainable future for the Revive Adserver Download edition. A Bright Outlook for Users In summary, the continuation of the Revive Adserver open source project under the umbrella of Aqua Platform heralds a new era. Users can rest assured that the software’s development and maintenance remains well-supported, thanks to the long term financial stability brought about by Aqua Platform. The synergy between Patreon sponsors and Aqua Platform creates a model where user support directly contributes to the advancement of the software. The post The Future of the Revive Adserver open source project with Aqua Platform appeared first on Revive Adserver. [url={url}]View the full article[/url]

Andrew Hill is leaving the Revive Adserver project team Farewell to Andrew Hill, Architect of Revive Adserver’s Success It is with mixed emotions that we announce Andrew Hill’s departure from the Revive Adserver project team. Andrew has played a pivotal role since 2013 when he spearheaded the acquisition of the open-source code from the previous maintainer. Under his guidance, we successfully launched Revive Adserver in September of that year, marking a new era for the project. Andrew’s commitment to the project has been unwavering, contributing tirelessly for over a decade. His expertise and dedication have been instrumental in the project’s growth and success. In 2015, he demonstrated his entrepreneurial spirit by creating a successful Patreon program, securing crucial support for the project’s ongoing development. In addition to his technical contributions, Andrew invested countless hours in enhancing the documentation website, ensuring that users could navigate and implement the software seamlessly. His active involvement in the community forums reflected his commitment to fostering a supportive and collaborative environment. All the time, energy, and inspiration he invested in the project has brought it to where it stands today, and we couldn’t have achieved this without him. However, in recent years, Andrew has been increasingly prioritizing family, personal pursuits, and other professional endeavors. After careful consideration, he has made the difficult decision to step away from the project. We express our deepest gratitude for Andrew’s invaluable contributions to the documentation website, community forums, and overall project development. We commend his warm and positive style of team play, and his impact on the project and the team will be lasting. We wish him the very best in all his future personal and professional endeavors. The post Andrew Hill is leaving the Revive Adserver project team appeared first on Revive Adserver. [url={url}]View the full article[/url]

Celebrating the 10th Anniversary of Revive Adserver A Decade of Collaboration and Dedication: Celebrating the 10th Anniversary of Revive Adserver It’s with great joy and pride that we celebrate the 10th anniversary of the Revive Adserver open source project. In an era of dominance by big tech, Revive Adserver has stood the test of time, emerging as an independent, powerful and versatile tool that empowers countless publishers, advertisers, and developers. Let’s take a moment to reflect on this remarkable journey and the impact it has had on the world of online advertising, and to look forward to the future. The Genesis In 2013, our project was born out of the realization that there was a continuing need for a reliable, flexible, and cost-effective ad serving solution that does not rely on huge corporations. Building upon the legacy of OpenX Source and phpAdsNew, our passionate developers set out to maintain and continue developing the free and open-source alternative that would democratize the world of online advertising. We named it Revive Adserver. Our vision was to provide a robust platform that could suit the needs of individuals and organisations of all sizes, and in all corners of the world. The Evolution Over the past ten years, Revive Adserver has proven to be a comprehensive, yet easy to use, ad management system with a global community of users and contributors. With regular updates, and improvements, Revive Adserver has remained a significant force in the ever-changing landscape of digital advertising. Key Milestones International Reach: Revive Adserver enjoys international recognition, thanks to its multi-language support and active global community. Security and Privacy: In an era of increasing concern for user privacy and data security, Revive Adserver has continuously improved to align with industry standards and regulations. Since the software is entirely open source, anyone can investigate the source code, and make sure that it is a safe and secure product. Community Engagement: The active community of users and developers has been at the heart of Revive Adserver’s success. Their feedback, contributions, and support have been invaluable. Into The Cloud: in 2018, on our 5th anniversary, we announced the Revive Adserver Hosted edition, a software-as-a-service offering based on the exact same software that was already available as a Download edition. Since then, many hundreds of individuals, small businesses, and also larger companies and even huge global corporations have subscribed to the service. The Impact Revive Adserver has democratised digital advertising by giving individuals, non-profit organisations, and companies of all sizes, access to a powerful ad serving platform, without having to share their data (and that of their site visitors) with big tech companies. It has enabled publishers to monetize their content effectively, and advertisers to reach their target audience efficiently. By providing a transparent and open-source alternative, Revive Adserver has contributed to the sustainability and diversity of the online advertising ecosystem. The Past, Present, and Future As we celebrate the 10th anniversary of Revive Adserver, we look back at a remarkable journey marked by dedication, and a strong commitment to open-source principles. It’s a testament to the power of collaboration and the enduring impact of a project that aims to make online advertising software accessible to all. We look forward to playing our part in the next decade of growth and evolution, confident that Revive Adserver will continue to be at the forefront of open source digital advertising solutions Here’s to the past, present, and future of Revive Adserver – a beacon of open-source success in the world of online advertising! Happy 10th anniversary! The post Celebrating the 10th Anniversary of Revive Adserver appeared first on Revive Adserver. [url={url}]View the full article[/url]

Revive Adserver v5.5.0 released  Revive Adserver v5.5.0 released Sponsor of this release: We’re proud to release version 5.5 of the Revive Adserver software. This version introduces support for the VAST2 standard for video ads, an extension of the support for video ads that has been part of Revive Adserver for many years. This was made possible by a generous donation from Aqua Platform, the company specializing in enterprise grade hosting of the Revive Adserver software. Aqua Platform donated the VidiX plugin, their commercially available product, to be included as a standard, free component of Revive Adserver. Many thanks to Aqua Platform for their continued support of our project. Version 5.5 also contains a number of bug fixes and a small security improvement. Please continue reading these releases notes for the full details.  New features and functionality in this version Version 5.5 of the Revive Adserver software contains a number of new features: We bundled the VAST2 Enhanced Video Ads plugin, enabling support for this IAB video ads protocol. This unlocks the ability to create video ads that – in turn – consist of VAST2 tags from third-party applications, and it also enables the user to generate VAST2 tags that can be used in any VAST2 compliant video player or in any VAST2 third-party ad serving system.  Improvements and enhancements in this version We added experimental command line install / update scripts, enabling system administrators to install or update the software from the command line. This functionality is for experienced sysadmins only and should – for the time being – only be used on test and staging environments. Documentation on how to use these scripts is forthcoming.  Bugs fixed in this version This version of Revive Adserver fixes a number of bugs: We fixed an issue preventing plugin hook “addUrlParams” from being called when generating click URLs since the introduction of the signed clicks functionality. We fixed an issue preventing click-based conversion tracking from properly working. We fixed an issue preventing password recovery from working properly when using a Postgres database. We added a missing check for the tokenizer PHP extension during install and upgrade. We fixed the zone delete action being always displayed regardless of the actual permissions. We fixed the “Export Statistics to Excel” functionality so that the link is only disabled when the selected range has no statistics at all. We fixed usage of specific charset with SPC (single page call) on local invocation. We fixed an uncommon issue preventing maintenance from properly completing in edge cases.  Non-Backward Compatible Changes This version of Revive Adserver has a non-backward compatible change: We removed support for creating new inline video ads using FLV type and/or streaming format. Backwards compatibility for delivery is retained, meaning that banners that were created with older version and that still exist in the database will continue to work.  Security improvements This version of Revive Adserver contains a fix for a very low risk security issue that was reported to us through our HackerOne program. We’ve posted a security advisory on this issue.  Contributions by community members We would like to thank the following community members for their contribution to this release: @kavit-gangar – #1428 @archiewestermann – #1420 @spantaleev – #1399 @pmacko – #1426 @camlafit – #1403  Download Download Revive Adserver v5.5.0 from our Library h Install How to install Revive Adserver on your own server h Update How to update Revive Adserver to a new version  Revive Adserver Hosted edition If you’d like to take advantage of all the features and benefits of the Revive Adserver software, without having to take care of the installation on your own server, software updates, and performance tuning, we’d like to suggest having a look at Revive Adserver Hosted edition. For a modest monthly fee, we’ll take care of all the technical work, all you have to do is log in and get started. The post Revive Adserver v5.5.0 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

If you're not subscribed yet, but are planning to, see https://www.revive-adserver.net/blog/elite-pricing-plan-for-hosted-edition-features-and-benefits/ for details on the Elite pricing plan.

We have no record of anyone with your email having a subscription at Revive Adserver Hosted edition.

Video ads functionality in Revive Adserver software will be updated to VAST2 We are thrilled to share an exciting collaboration between Aqua Platform and Revive Software and Services, aimed at providing additional value to users of the Revive Adserver software. Aqua Platform, the creator of the VidiX plugin, is transferring this powerful plugin to Revive Software and Services, the makers of the popular, free, open source Revive Adserver software. Starting September 2023, the VidiX plugin will be seamlessly incorporated into Revive Adserver, enhancing its video ads functionality and creating new video advertising opportunities for users worldwide. Aqua Platform takes immense pride in supporting the open source community through their contribution of the VidiX plugin. The Managing Director of Aqua Platform, Erik Geurts, expressed his enthusiasm, saying: “We are truly proud to contribute the VidiX plugin to the open source community. By making it available to all users of Revive Adserver, we aim to empower publishers and other organisations to make optimal use of video ads for their video content, just like they’ve been doing with traditional display ads for over 2 decades. It’s a great opportunity for us to contribute to the open source project that has been instrumental in creating and growing our company.” The project team at Revive Software and Services is immensely grateful for the generosity of Aqua Platform in sharing the VidiX plugin. This contribution opens up new possibilities for Revive Adserver users around the globe. The team expressed their appreciation, with Lead Developer Matteo Beccati stating: “We extend our heartfelt thanks to Aqua Platform for entrusting us with the VidiX plugin. This collaboration marks a significant milestone in our mission to offer a comprehensive and powerful free open source advertising management system. With the VidiX plugin, we will be able to extend and enhance Revive Adserver to become VAST2 compliant, making it even more valuable and useful for our users.” Aqua Platform and Revive Software and Services are eagerly anticipating the next version of Revive Adserver in September 2023, marking the 10 year anniversary of its initial release in September 2013. This collaboration reflects their shared vision of meeting the evolving needs of ad supported businesses worldwide. The collaboration between Aqua Platform and Revive Software and Services marks an exciting chapter in the evolution of Revive Adserver. With the transfer of VidiX plugin and its incorporation into Revive Adserver, both companies are paving the way for enhanced business opportunities through video advertising for its users. Together, they are reinforcing their commitment to supporting the community. Stay tuned for the launch of the enhanced Revive Adserver in September 2023, and join us in celebrating this milestone. The post Video ads functionality in Revive Adserver software will be updated to VAST2 appeared first on Revive Adserver. [url={url}]View the full article[/url]

We just released Revive Adserver v5.4.1 The new version 5.4.1 of the Revive Adserver software contains fixes for a number of small bugs and inconveniences that have been identified after publication of v5.4.0. Changes in v5.4.1 of the Revive Adserver software: We fixed an issue causing “permission denied” errors in some statistics screens, e.g. banner / zone history. We restored the Export Statistics to Excel functionality, mistakenly removed in version 5.4.0. To clarify, the feature was still there, but the link was accidentally removed. We fixed an incompatibility between the {clickurl} macro and other magic macros, e.g. {random}, when used together in a destination URL. We fixed SQL errors for those using the Postgres database system, when displaying some cross entity history stats screens, e.g. campaign / website. We fixed an issue detecting campagin start/end date overlap when linking banners to newsletter zones under some circumstances. Full release notes for v5.4.1 can be found on our Github page. Download, install and upgrade Revive Adserver v5.4.1 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. 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.4.1 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

We are proud to release Revive Adserver v5.4.0 Revive Adserver v5.4.0 introduces improved password functionality for new and existing users, and provides compatibility with PHP 8.1. We’ve implemented significant improvements to the way Revive Adserver handles end-user passwords: Bcrypt is now used to store password hashes, replacing md5. The password of the admin user is automatically re-hashed while performing the update to v5.4.0. All other users users will be sent an email upon login, asking them to enter a new password. The minimum password length is now set to 12 characters. This default length can be changed in the configuration file. We’ve added a welcome email for new users, to prompt them to set up their own password. We’ve added a password strength indicator during installation and password set up / recovery, based on MIT licensed Dropbox’s zxcvbn library. We’ve added autocomplete attributes for username and password fields, for example to help password managers more easily recognize user credentials and suggest strong passwords. For more info about these changes, please refer to the page at https://www.revive-adserver.com/faq/passwords-in-v5-4-0/ There are also a number of other changes and improvements in this release: We’ve added support for PHP 8.1. We’ve added support for WEBP format in image and HTML5 banners. Website invocation code generation now uses async tags. Asynchronous tag now sends a custom “revive-<ID>-loaded” JS event when loading each banner and a “revive-<ID>-completed” event when all the positions on the page have been filled. This allows interaction and customization, e.g. dynamically adding a class to all image banners. Tags are now generated using https by default, with the possibility to use plain http instead in the invocation code screens. We’ve added banner delivery setting to configure the “rel” HTML attribute for the click tracking links of image and text banners, defaulting to “noopener nofollow”. The setting is also exposed in the newly added “{rel}” magic macro. We’ve added a new maintenance screen to resend invitation emails to new users and password reset emails to users requiring the update to the new bcrypt password hash system. We’ve added missing linkUserToAdvertiserAccount, linkUserToTraffickerAccount and linkUserToManagerAccount methods to the v2 XML-RPC Api client library and fixed bugs related to (re)setting permissions through them. This version also fixes a number of bugs and has one security improvement: We’ve fixed a prioritization issue when setting the “to_be_delivered” flag introduced in 5.3.0. We’ve fixed an issue parsing and modifying “var clickTag = ”;” in HTML5 banners when there is no whitespace around the equal sign. We’ve fixed an issue allowing the installation to proceed when entering two non matching admin passwords, as long as the “Repeat password” field was not empty. Password recovery e-mails were sent using the user name rather than the contact name in the To: header, this has been fixed. Password recovery landing screen is no longer English-only, instead it loads the user’s defined language instead. The full release notes are available on the project’s Github pages. Download, install and upgrade Revive Adserver v5.4.0 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. 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.4.0 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Revive Adserver project team is proud to announce that a Release Candidate 1 (RC1) is now available for the upcoming Revive Adserver v5.4.0. Introducing Revive Adserver v5.4.0 The new version 5.4.0 wil support PHP 8.1.x, and it introduces a number of improvements and changes to how Revive Adserver handles user passwords. There are also a number of smaller improvements and bug fixes. In order to give users of the Revive Adserver software the opportunity to thoroughly test this new version, we’ve put together this release candidate. Summary of changes in Revive Adserver v5.4.0 We’ve implemented significant improvements to the way Revive Adserver handles end-user passwords: Bcrypt is now used to store password hashes, replacing md5. The password of the admin user is automatically re-hashed while performing the update to v5.4.0. All other users users will be sent an email upon login, asking them to enter a new password. The minimum password length is now set to 12 characters. This default length can be changed in the configuration file. We’ve added a welcome email for new users, to prompt them to set up their own password. We’ve added a password strength indicator during installation and password set up / recovery, based on MIT licensed Dropbox’s zxcvbn library. We’ve added autocomplete attributes for username and password fields, for example to help password managers more easily recognize user credentials and suggest strong passwords. For more info about these changes, please refer to the page at https://www.revive-adserver.com/faq/passwords-in-v5-4-0/ There are also a number of other changes and improvements in this release: We’ve added support for PHP 8.1. We’ve added support for WEBP format in image and HTML5 banners. Website invocation code generation now uses async tags. Asynchronous tag now sends a custom “revive-<ID>-loaded” JS event when loading each banner and a “revive-<ID>-completed” event when all the positions on the page have been filled. This allows interaction and customization, e.g. dynamically adding a class to all image banners. Tags are now generated using https by default, with the possibility to use plain http instead in the invocation code screens. We’ve added banner delivery setting to configure the “rel” HTML attribute for the click tracking links of image and text banners, defaulting to “noopener nofollow”. The setting is also exposed in the newly added “{rel}” magic macro. We’ve added a new maintenance screen to resend invitation emails to new users and password reset emails to users requiring the update to the new bcrypt password hash system. We’ve added missing linkUserToAdvertiserAccount, linkUserToTraffickerAccount and linkUserToManagerAccount methods to the v2 XML-RPC Api client library and fixed bugs related to (re)setting permissions through them. This version also fixes a number of bugs and has one security improvement: We’ve fixed a prioritization issue when setting the “to_be_delivered” flag introduced in 5.3.0. We’ve fixed an issue parsing and modifying “var clickTag = ”;” in HTML5 banners when there is no whitespace around the equal sign. We’ve fixed an issue allowing the installation to proceed when entering two non matching admin passwords, as long as the “Repeat password” field was not empty. Password recovery e-mails were sent using the user name rather than the contact name in the To: header, this has been fixed. Password recovery landing screen is no longer English-only, instead it loads the user’s defined language instead. The full release notes are available on the project’s Github pages. Staging Only! Today’s RC1 should not be used in a production environment. We would like to invite system administrators and developers to install it in a staging environment, or to make a copy of their production environment and update that copy to this new version. If you’d like to do a fresh install of this release candidate, please see the instructions for installing Revive Adserver on the website. A detailed process for updating the Revive Adserver software can be found on the website as well. Update path of Revive Adserver and PHP Any versions of Revive Adserver prior to v5.3.0 will not run with PHP8, whereas Revive Adserver v5.4.0 won’t run on PHP versions prior to 7.2.5. Please note that Revive Adserver v5.4.0 does not yet run on PHP 8.2. Support for that upcoming release of PHP will be part of a future release of Revive Adserver. If all else fails, you might consider following this update path: Update Revive Adserver to version 5.2.1 if still using an older version Update the server to PHP version 7.2.5 or higher, but not PHP 8 Update Revive Adserver to version 5.4.0-RC1 Update the server to PHP version 8.0.x or even PHP version 8.1.x. Technical requirements for PHP 8 can be found on the php.net website. Updating MySQL It is recommended to update MySQL to v8 only after a successful update of Revive Adserver to v5.3.0 or higher. Download now! Release Candidate 1 of Revive Adserver v5.4.0 can be downloaded now from the Downloads page of the website. Reporting issues Any issues or bugs found during the installation, update, or use of the v5.3.0 RC1 should be reported only by creating a new issue in our Github repository. However, before doing so, please check to see if the issue you noticed has already been reported, and consider adding a comment about any additional observations to the issue instead. The issue you observed may have already been fixed. Please try to be as specific as possible, including any error log entries you might be able to provide, and/or screenshots of the issue. Describe what you were trying to do, what you expected to happen, and what actually happened instead. Make sure to mask any sensitive details like usernames, passwords, paths and URLs. Timeline for final release of v5.4.0 Our current plan is to have a final release of v5.4.0 available on April 14, 2022. However, this may have to be delayed due to pending issues at that time. You can follow our progress towards completing the v5.4.0 release on our Github page. Community contributions The continued development of Revive Adserver is being sponsored by community members, either financially or in the form of code contributions. We’re very grateful for the support we’ve received. If you would like to contribute to our project financially, 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 Release Candidate 1 for Revive Adserver v5.4.0 appeared first on Revive Adserver. [url={url}]View the full article[/url]

After the Log4j vulnerability was disclosed in early December 2021, we investigated to find out if the Revive Adserver software is impacted by this matter. This was also prompted by an issue that was opened by a user on our Github repository. This user ran a file checker, which reported that a file in the Revive Adserver software contains log4j files. The aforementioned file appears to has been introduced over a decade ago along with the example XML-RPC Java API client, and had possibly been intended for some automated tests of said API. If our published security guidelines are implemented, the affected jar file is not accessible from the outside. It is also not being used by Revive Adserver software in any way. As such, there is no indication that the Revive Adserver software is affected by the Log4j vulnerability. We will most likely remove the sample Java client and its supporting jar files in a future release of Revive Adserver, as these files are not being maintained and haven’t been tested for ages. This should also help avoid unnecessary file detection reports by log4j vulnerability scanners. Please follow the original Github issue and any comments posted there to stay up to date about this particular topic. Please also take note about our Security advisories. If you think you’ve found an actual vulnerability, please report it to us responsibly through our HackerOne security reporting program. The post Revive Adserver not impacted by the Log4j vulnerability appeared first on Revive Adserver. [url={url}]View the full article[/url]

We just released Revive Adserver v5.3.1 The new version 5.3.1 of the Revive Adserver software fixes a number of bugs that have been identified after publication of v5.3.0. Changes in v5.3.1 of the Revive Adserver software: We added missing “from” and “to” labels in the date selectors of the statistics screens. We fixed an issue preventing tracker account preferences from being displayed in the menus. We fixed an issue causing “access denied” error messages on some statistics pages, e.g. campaign banners. We fixed the ‘redirection upon click’ on legacy image tags leading to a white page instead of the destination URL of the banner. We fixed some PHP fatal errors in the XML-RPC API v2. We fixed a PHP fatal error in admin-search.php on PHP 8.0. We fixed PHP fatal error in banner-zone.php on PHP 8.0. Full release notes for v5.3.1 can be found on our Github page. Non-backward compatible changes A PHP version equal to or higher than 7.2.5 is now required to run Revive Adserver 5.3.0 or higher. The mysql4_compatiblity setting has been removed: Revive Adserver will now always make sure that the appropriate (empty) sql_mode is set when running on a MySQL database. Support for the legacy pecl msqyl extension has been removed: mysqli will always be used instead. Download, install and upgrade Revive Adserver v5.3.1 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. 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.3.1 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

We are proud to release Revive Adserver v5.3.0 This version ensures that Revive Adserver is compatible with both PHP 8.0 and MySQL 8.0. While there is no new functionality in this new release, it did require a major undertaking to check and modify the entire code base in order to achieve this level of compatibility. Here is a list of changes and and improvements in Revive Adserver v5.3.0: We added PHP 8.0 compatibility. We added MySQL 8.0 compatibility. We added compatibility for the MySQL ‘utf8mb4’ character set. We also fixed a number of bugs in this version 5.3.0 of Revive Adserver: We fixed hourly breakdown statistics links from daily history pages not working properly. We added missing support for SSL connections to MySQL databases in the delivery scripts. We fixed multiple issues related to upgrading plugins, especially on PHP8. We removed a useless option to add a cache buster when generating async tags. we fixed an issue with the maintenance delivery rules check screen not properly working. Full release notes for v5.3.0 can be found on our Github page. Non-backward compatible changes A PHP version equal to or higher than 7.2.5 is now required to run Revive Adserver 5.3.0 or higher. The mysql4_compatiblity setting has been removed: Revive Adserver will now always make sure that the appropriate (empty) sql_mode is set when running on a MySQL database. Support for the legacy pecl msqyl extension has been removed: mysqli will always be used instead. Security fix This version 5.3.0 contains a fix for a low risk security issue that was recently discovered: Session ID and CSRF token generation now uses CSPRNG instead of uniqid(). A more detailed security advisory is available at https://www.revive-adserver.com/security/revive-sa-2021-005/ This version 5.3.0 also contains a security improvement: Database password is no longer returned in the database settings form. We recommend upgrading to the most recent 5.3.0 version of Revive Adserver as soon as possible. Download, install and upgrade Revive Adserver v5.3.0 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. 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.3.0 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

Revive Adserver turns 8! Revive Adserver turns 8! Today we celebrate the 8th anniversary of the Revive Adserver project. On September 13, 2013, we unveiled the new Revive Adserver open source project, and released a brand new version 3.0 to the world. Although the software already had a long history at the time, the predecessor of Revive Adserver did not get the love and care it deserved. Our project team was created to take the ad serving system under its wings and revitalize it. Here is a very brief rundown of some of the many things we achieved in the 8 years since. Download edition – from 2013 Since that first release of version 3.0.0 in September 2013, we’ve continued working on making the software faster, more secure, and more powerful. There have been over 30 new releases in these 8 years. To date, there are more than 6,000 known self-hosted installations of the Download edition, and probably many more we don’t know about. Revive Software and Services – from 2015 In order to secure the future of the Revive Adserver open source project, we formed a legal entity called Revive Software and Services in 2015. The goal of this company was and still is to act as the guardian of the intellectual property rights for the software even when project members may not be participating in the future. It also enables us to correctly handle sponsorships and paid services, for example in light of fiscal regulations, and to work with outside vendors, contractors, service providers and (who knows, in the future) paid employees. Patreon – from 2017 In 2017, we created a Patreon program, enabling companies and individuals using Revive Adserver to share a small (or large) portion of the revenue they make with the ad server with our project. A loyal group of sponsors contribute to our project every month. Most of them have set their contribution to $10 per month, but we’re also incredibly grateful that a few sponsors contribute as much as $150 every month. Hosted edition – from 2018 On the 5 year project anniversary in 2018, we announced the creation of a hosted service for Revive Adserver. This service is intended for people interested in using the software, but lacking the time, skill, resources or patience to install, configure and maintain a self-hosted ad server. The Revive Adserver Hosted edition took off in a big way after we started inviting subscribers in the fall of 2018. Nowadays, hundreds of subscribers use the service every single day, in order to display hundreds of millions of ads every month. Check out Revive Adserver Hosted edition Thanks to the community! The continued use of our software by a large community is what drives us to keep going. It’s very rewarding to work on a free, open source, ad serving system that is a real alternative to the huge and anonymous corporate ad systems that seem to dominate the internet these days. Revive Adserver enables companies, big and small, to take control of the advertising on their sites and apps, without having to worry about what will happen with their data. This also motivated us to take on a large project in 2021. In the year when we celebrate our 8th anniversary, we’re releasing the next version of Revive Adserver that supports both PHP 8 and MySQL 8. Version 5.3.0 will be released on September 14, 2021. Watch this space! Revive Adserver blog The post Revive Adserver turns 8! appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Revive Adserver project team is proud to announce that a Release Candidate 1 (RC1) is now available for the upcoming Revive Adserver v5.3.0. Introducing Revive Adserver v5.3.0 The primary goal of v5.3.0 is to provide compatibility with PHP 8 and MySQL 8. This version has no new features or functionality, but it does fix a number of bugs and has a small security improvement. So while this may not be a terribly exciting new release from an end-user perspective, a huge number of changes have been made in the code to achieve compatibility with PHP8 and MySQL 8. This justifies a thorough testing phase before the final release. Summary of changes in Revive Adserver v5.3.0 New in this version: Added PHP 8.0 compatibility. Added MySQL 8.0 compatibility. Added compatibility for the MySQL ‘utf8mb4’ character set. This version also fixes a number of bugs and has one security improvement: Fixed hourly breakdown statistics links from daily history pages not working properly. Added missing support for ssl connections to MySQL databases in the delivery scripts. Fixed multiple issues related to upgrading plugins, especially on PHP8. Removed useless option to add a cache buster when generating async tags. Database password is no longer returned in the database settings form. The full release notes are available on the project’s Github pages. Staging Only! Today’s RC1 should not be used in a production environment. We would like to invite system administrators and developers to install it in a staging environment, or to make a copy of their production environment and update that copy to this new version. If you’d like to do a fresh install of this release candidate, please see the instructions for installing Revive Adserver on the website. A detailed process for updating the Revive Adserver software can be found on the website as well. Update path of Revive Adserver and PHP Any versions of Revive Adserver prior to v5.3.0 will not run with PHP8, whereas Revive Adserver v5.3.0 won’t run on PHP versions prior to 7.2.5. If all else fails, you might consider following this update path: Update Revive Adserver to version 5.2.1 if still using an older version Update the server to PHP version 7.2.5 or higher, but not PHP 8 Update Revive Adserver to version 5.3.0-RC1 Update the server to PHP version 8.0.x Technical requirements for PHP 8 can be found on the php.net website. Updating MySQL It is recommended to update MySQL to v8 only after a successful update of Revive Adserver to v5.3.0 or higher. Download now! Release Candidate 1 of Revive Adserver v5.3.0 can be downloaded now from the Downloads page of the website. Reporting issues Any issues or bugs found during the installation, update, or use of the v5.3.0 RC1 should be reported only by creating a new issue in our Github repository. However, before doing so, please check to see if the issue you noticed has already been reported, and consider adding a comment about any additional observations to the issue instead. The issue you observed may have already been fixed. Please try to be as specific as possible, including any error log entries you might be able to provide, and/or screenshots of the issue. Describe what you were trying to do, what you expected to happen, and what actually happened instead. Make sure to mask any sensitive details like usernames, passwords, paths and URLs. Timeline for final release of v5.3.0 If necessary, a second release candidate will be posted in the week of August 16, 2021. Our current plan is to have a final release of v5.3.0 available on September 13, 2021. However, this may have to be delayed due to pending issues at that time. You can follow our progress towards completing the v5.3.0 release on our Github page. Community contributions The continued development of Revive Adserver is being sponsored by community members, either financially or in the form of code contributions. We’re very grateful for the support we’ve received. If you would like to contribute to our project financially, 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 Release Candidate 1 for Revive Adserver v5.3.0 appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Revive Adserver team is proud to announce the immediate availability of Revive Adserver v5.2.1. We are pleased to announce the release of version 5.2.1 of the Revive Adserver software. This version contains several improvements, and fixes a bug and a low risk security issue. Here is a list of improvements in Revive Adserver v5.2.1: We added a security check in the admin UI that verifies upon login and on demand if the browser can access files that should be forbidden, eventually prompting the admin to fix the potential security problem. Several major languages were missing from the Client Language delivery rule: the list has been revised and updated. We fixed a bug in this version 5.2.1 of Revive Adserver: We fixed an issue preventing clicks from redirecting to the destination URL on newsletter zones. Full release notes for v5.2.0 can be found on our Github page. Security fixes This version 5.2.1 contains a fix for a low risk security issue that was recently discovered: Reflected XSS vulnerability in stats.php via the statsBreakdown parameter. A more detailed security advisory is available at https://www.revive-adserver.com/security/revive-sa-2021-004/ We recommend upgrading to the most recent 5.2.1 version of Revive Adserver as soon as possible. Download, install and upgrade Revive Adserver v5.2.1 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. 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.2.1 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

About the changes to click tracking in Revive Adserver v5.1 and v5.2 This blog post is a deep dive into the changes to the click tracking functionality of the Revive Adserver software, with the recent versions 5.1 and 5.2. Introduction There have been two major releases of the Revive Adserver software in recent weeks. Version 5.1 came out on January 19, 2021 and version 5.2 was released on March 16, 2021, exactly 8 weeks later. The most significant changes in these two versions have to do with the ability to count clicks on third party ad tags. In this blog post, we’ll dive deeper into what has been changed, and why. Click tracking changes in v5.1 In the last quarter of 2020, we started receiving more and more reports that Revive Adserver’s “open redirect” capability was being abused by malicious actors. They would craft links that looked innocent or trustworthy, but ultimately redirect unsuspecting web users to pages that could only be described as spammy or even scammy. Even though the ad server itself didn’t run any particular risk from this behavior, it could harm the reputation of the organization or individual operating the ad server. The open redirect capability was the industry standard implementation for click counting functionality (a.k.a. click tracking), which is an essential part of any ad server. One of the most important changes in version 5.1 was the removal of the software’s ability to perform an open redirect. It was replaced by a new click tracking feature that adds a unique signature to any click link that Revive Adserver creates. Without a valid signature, Revive Adserver v5.1 will simply refuse to redirect the person clicking the link to the manipulated destination, and instead it will just redirect to the actual destination URL as defined with the banner that was just clicked. While working on the changes in Revive Adserver v5.1, we also evaluated the so-called ‘3rd Party Servers’ plugin that has been shipping with Revive Adserver for ages. Our evaluation confirmed that all of these third party ad servers were either no longer in business, or had changed so much in recent years that the automatic click trackers that Revive Adserver attempted to insert into third party tags, no longer worked. That resulted in the decision to remove the 3rd Party Servers plugin from Revive Adserver starting with v5.1. We also changed the functionality related to Revive Adserver zone invocation codes for inclusion in other ad servers. This is for the scenario where a zone invocation code (a.k.a. tag) from Revive Adserver is entered into another ad server to act as a creative there. Before v5.1 it was possible to define the tag so that it would be possible to count a click on a banner delivered through the combination of both ad servers. Both Revive Adserver and the external ad server would be able to count the click. Revive Adserver had a parameter ‘ct0’ for this. This feature also relied on the ability to perform an open redirect, and since this was being removed with v5.1, the ct0 parameter also needed to be removed. Click tracking reworked in v5.2 After the release of v5.1 in January 2021, we started receiving messages from users, from subscribers of the Revive Adserver Hosted edition, and from customers of some of our partners like Aqua Platform, that they were disappointed that the features for integration of click counting between Revive Adserver and external ad servers was removed. For example, a very common scenario is to take javascript tags from Google’s DCM system (primarily used by large advertisers and agencies), and to paste these into Generic HTML banners in Revive Adserver. While the ads would display just fine, and DCM was perfectly able to count any clicks on them, Revive Adserver software v5.1 was no longer able to count such clicks. For this use case, Revive Adserver v5.2 has a reworked ability to use the {clickurl} macro in third party ad tags, which have the characteristic that the ultimate destination URL is unknown to Revive Adserver. For this scenario, a new click URL validity setting has been created, which defines the length of time that the click link will be allowed to perform a redirect, after it has been generated by Revive Adserver. This functionality uses the recently introduced signing mechanism to protect the links from being tampered with. The validity is expressed in seconds, and by default, it is set to 0 seconds, meaning it is disabled. Setting the value to anything higher than zero results in click links that remain functional for that length of time. It is recommended to use a relatively short validity window, for example 600 seconds (10 minutes), or at least no longer than 3600 seconds (1 hour). If a malicious actor attempts to abuse the redirect capability of these signed and time-restricted click links, by putting them into spam mails, or by submitting them in contact forms, or any other type of scenario, this will no longer work after the validity window expires. Attempts to manipulate the timestamp in the click link won’t work either, because that will result in an invalid signature. The signatures that Revive Adserver generates for the click links are extra secure because they’re also based on a randomly generated and unique seed value that’s unknown externally, and unique to every installation of the software. Any attempt to manipulate the click link will result in the Revive Adserver software simply not redirecting the user anywhere. As such, it is now almost impossible for threat actors to abuse the feature, at least not at scale and only within a short window of opportunity. We feel this is a reasonable compromise between functionality and security. If you don’t want to open up your ad server to redirects at all, simply leave the clickValidity setting at its default value of 0 (zero) seconds. Additionally, the support for Revive Adserver zone invocation codes being included in other ad servers via the ct0 parameter has been reimplemented in a way that causes no open redirect. For the time being, users who want to use the ct0 parameter will need to manually insert it into invocation codes, we are considering the development of a special plugin to help with this in the future. The post About the changes to click tracking in Revive Adserver v5.1 and v5.2 appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Revive Adserver team is proud to announce the immediate availability of Revive Adserver v5.2.0. We are pleased to announce the release of version 5.2.0 of the Revive Adserver software. This version contains new features and improvements related to click tracking, and it fixes several bugs and two low risk security issues. Here is a list of new features and improvements in Revive Adserver v5.2.0: Protocol relative URLs (e.g. “//example.com”) are now recognized as valid destinations when altering HTML banners to add click tracking. We now allow optional custom destinations in HTML banners using the “{clickurl}” macro and dynamically appending a URL-encoded destination. The new click URL validity setting specifies the number of seconds a generated click URL will be accepted and will redirect to the specified destination parameter. The feature is disabled by default to avoid abuse. The “ct0” parameter has been reworked and reintroduced. Revive Adserver tags can now be modified so that they can be placed into third party ad servers and have both ad servers track ad clicks. We replaced “product name” with “application name” in the recently redesigned password recovery emails. We fixed a number of bugs in this version 5.2.0 of Revive Adserver: Issue with password recovery emails being sent to the administrator or not being sent at all. Issue with determining the real IP addresses of viewers behind a proxy server when proxy headers contained the origin port number. PHP errors in ck.php and cl.php when no banner/zoneid were provided. PHP errors preventing the video reports from properly functioning. Issue preventing the “bannertext” property from being added or modified using the API. Issue preventing the “Don’t count ad clicks… within the specified time” feature from working as expected. Issue in the legacy JavaScript tag generation. All the non-async JS tags generated in v5.1.x should be replaced with new ones, as they could break the layout of the websites they have been placed onto. Issue with site variable magic macro detection in the destination URL. The option to “track Google AdSense clicks” when generating iframe tags, which was a leftover from the removal of the non-working functionality that had already been removed, has also been removed. Reverted and made optional the change to use srcdoc when rendering async tags as it is not fully compatible with some third party tags. However, the behavior can be selected by adding data-revive-srcdoc=”1″ as an attribute of the ins HTML tag. Full release notes for v5.2.0 can be found on our Github page. Security fixes This version 5.2.0 contains fixes for some low risk security issues that were recently discovered: Reflected XSS vulnerability in campaign-zone-zones.php via the status parameter. Reflected XSS vulnerability in stats.php via the statsBreakdown parameter. A more detailed security advisory is available at https://www.revive-adserver.com/security/revive-sa-2021-003/ We recommend upgrading to the most recent 5.2.0 version of Revive Adserver as soon as possible. Download, install and upgrade Revive Adserver v5.2.0 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. 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.2.0 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

The Revive Adserver team is proud to announce the immediate availability of Revive Adserver v5.1.1. We are pleased to announce the release of version 5.1.1 of the Revive Adserver software. This new version fixes two bugs in the previous v5.1.0, and addresses two low risk security issues that have been discovered recently. We fixed two bugs in this version 5.1.1 of Revive Adserver: We fixed newsletter zones ad delivery and legacy remote invocation. We fixed an issue preventing checkboxes and delete button from appearing on the advertisers list, even when the user had proper permission to delete inventory items. Full release notes for v5.1.1 can be found on our Github page. Security fixes This version 5.1.1 contains fixes for two low risk security issues that were recently discovered. A detailed security advisory is available at https://www.revive-adserver.com/security/revive-sa-2021-002/ We recommend upgrading to the most recent 5.1.1 version of Revive Adserver as soon as possible. Download, install and upgrade Revive Adserver v5.1.1 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. 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.1.1 released appeared first on Revive Adserver. [url={url}]View the full article[/url]

What’s New? in Revive Adserver v5.1 This blog post provides a detailed description of the changes and enhancements in version 5.1 of the Revive Adserver software, including an explanation of the reasons behind some of the changes. Introduction On January 19, 2021, we released version 5.1 of Revive Adserver. The release notes for the new version list the changes, enhancements and improvements in a technical manner. We thought it might prove useful to provide some more detailed descriptions and explanations about the changes. Improved Password Recovery Emails We have reworded the email message that is sent to users when they request a password reset. These emails were not very informative in the past, so they sometimes caused confusion. The new text looks similar to this example: Dear recipient, You, or someone pretending to be you, recently requested that your Revive Adserver password be reset. If this request was made by you, then you can reset the password for your username ‘{username}’ by clicking on the following link: <link appears here> If you submitted the password reset request by mistake, or if you didn’t make a request at all, simply ignore this email. No changes have been made to your password and the password reset link will expire automatically. If you continue to receive these password reset mails, then it may indicate that someone is attempting to gain access to your username. In that case, please contact the support team or system administrator for your Revive Adserver system, and notify them of the situation. Accounts can be active, suspended, or inactive The Revive Adserver software has the ability to house multiple accounts. These can be useful, for example, if one installation of the software is to be used by multiple business units of a larger organization, or if the software is used to provide commercial hosting services, such as the Revive Adserver Hosted edition. Especially in the latter case, it was found that subscribers often forget to remove the ad server codes from their websites when they cancelled their subscription. It also happens sometimes that the monthly renewal payment for their subscription fails. For these scenarios, we’ve introduced a setting with accounts that enable us to set it to either suspended or inactive. A suspended account is expected to be activated again once the renewal payment succeeds eventually, whereas an inactive account is associated with a cancelled subscription. Setting an account to either suspended or inactive could be useful in other scenarios as well. When a website triggers an ad request for a zone that’s part of an inactive or suspended account, the ad server will simply output an empty response, while still recording an ad request. Optionally, the system administrator can configure a message to be included with the response, for example “This ad server account has been suspended.” The messages that should be returned for a suspended or an inactive account can be defined in the Delivery settings in the “Configuration” tab of the Revive Adserver installation. Ad server response for a request to a non-existent zone When a website contains the zone invocation code for a zone that no longer exists, or has never existed, it slows down the website unnecessarily, and it also creates additional load on the ad server that should be avoided. To help webmasters discover and fix such invalid ad requests, a message can be configured to be returned by the ad server. This optional message could look something like this example: “Invalid ad request. Zone ID does not exist.”. The message that should be returned when a non-existent zone is requested ban be defined in the Delivery Settings in the “Configuration” tab. Prevent inventory items from being deleted by accident Up to the previous version of Revive Adserver, any user with account manager level access would be able to delete any of the inventory items such as advertisers, campaigns, banners, websites, or zones. Through feedback from users and subscribers at Revive Adserver Hosted edition, we learned that it was too easy to accidentally delete items, and users weren’t always aware that this also deleted any and all statistics associated with that item. For example, if a user deletes a zone, this deletes the statistics of the zone, and as a result also the statistics of all banners ever delivered through that zone. Since banner statistics sum into campaign statistics, this would have the unwanted effect of incomplete data for campaigns, which are often the basis for invoicing to customers (advertisers). It could also have the unexpected effect of re-activating campaigns that had previously expired when they reached their defined impression target. To prevent such accidents, a new account manager level permission to delete inventory items has been introduced in Revive Adserver v5.1. Users that are already present when updating to version 5.1 will not have the permission enabled by default. System administrators can simply tick a checkbox to add the permission to selected manager users. A system administrator will always be able to delete anything, since these users are expected to be knowledgeable about the consequences of doing so. Flash functionality removed In late December 2020, Adobe formally stopped providing support for their Flash software. The Revive Adserver software still contained a few features related to Flash, including the ability to upload Flash banners. This was despite the fact that modern browsers stopped supporting Flash a long time ago. Now that Flash is effectively gone, we’ve removed the ability to upload Flash banners, and any existing Flash banners still present in your inventory will no longer work either. Video ads previewer The Revive Adserver had a built-in video player to preview video ads, which used to be based on a Flash component. Since browsers no longer support Flash, this preview feature has been broken for a long time. With Revive Adserver v5.1, we’ve replaced this with a native HTML5 video player that’s supported by all modern browsers. Change for geotargeting in South Africa There has been a change in the ISO standard coding for two geographic subdivisions in South Africa. The code for ZA-GT was changed to ZA-GP, and ZA-NL was changed to ZA-KZN. In Revive Adserver v5.1 we’ve implemented this change as well. Any banners that use the codes that have been phased out will have to be changed manually to use the new codes. These banners will simply not be eligible for delivery until this change has been made. Bug fixes and security fixes The new version 5.1 of Revive Adserver also comes with fixes for a number of bugs, plus a few low risk security issues. The details can be found in the release notes and the security advisory, respectively. Anyone interested in the exact details of all the changes can have a look at the release notes and the change log of the new release. The post What’s new in Revive Adserver v5.1 appeared first on Revive Adserver. [url={url}]View the full article[/url]