Jump to content

IvorD

Approved members
  • Content Count

    6
  • Joined

  • Last visited

About IvorD

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm not sure our problems are the same. The problem I was addressing was someone taking one of our legitimate Revive ad URLs and replacing the "oadest" parameter with a different target than that specified for the banner so that Revive did the redirection to the bogus target. My solution was to ignore the oadest parameter when the banner ID is specified in the ad URL and use the URL associated with the banner instead. As I noted before, the open redirection problem has been described as an unavoidable feature of Revive, but so far nobody has pointed me to an explanation of why that is and I ha
  2. If $adId is empty then you have no banner whose URL should be used in place of the oadest URL. The problem I was solving was a request that contained both a banner ID and a bogus oadest. My change forces the use of the banner's URL when the banner ID is supplied, ignoring the oadest URL. It does not affect the behaviour if there is no banner ID provided. Sorry. The alternative would be to modify the procedure return an empty string if no $adId is specified, but I have no idea how often and/or where requests without a banner ID may be generated otherwise, so that modification might break some o
  3. Caveat: My solution below may or may not break something else of which I am not aware. I have not had ANY response to inquiries about under what circumstances the oadest URL would legitimately differ from the URL associated with the banner identified by the "bannerid" (aka "$adId") in the same query. I even asked someone directly who said they had spent hours unsuccessfully looking for a workaround to the open redirection requirement, but have had no response so far. It's evidently a deliberate design choice. I solved my problem (see previous post in this thread) in function MAX_querystri
  4. It looks like I can prevent this open redirection in MAX_querystringGetDestinationUrl by forcing it to use the ad's url when an ad is specified: if (/*empty($dest) &&*/ !empty($adId)) { $aAd = MAX_cacheGetAd($adId); if (!empty($aAd)) { $dest = $aAd['url']; } } Under what legitimate circumstances would the URL specified in the dest parameter for an ad click be different from the URL specified for the ad also identified in the click URL? (Our deployment is not as a general purpose/revenue-generating ad server, but a convenient way to track referral
  5. I asked a similar question back in 2019 on the Off Topic forum, but got no response and the problem has now cropped up again: We got alerted through the Google Search Console about a "bad" link on our website. The link cited was a Revive ad link in which a different URL from the target URL of the bannerid banner had been substituted for the oadest component of oaparams The substituted URLs are to porn sites, of course. Curiously, going through the last couple of months of Apache logs, I can only find requests for lots of similarly hijacked URLs (for the same banner and zone IDs) from we
  6. I'm posting to see if anyone has experienced anything as curious as the following: We received an alert from the Google Search Console about an invalid redirection. (I vetted the message to ensure it was legitimate.) The link they supplied was a Revive ad link from our server with legitmate zone and banner IDs but an incorrect destination URL: https://SITE/adserver/www/delivery/ck.php?oaparams=2__bannerid=16__zoneid=13__cb=bf7c125ee0__oadest=http://asmilingmalice.tumblr.com%22%3EBeautiful whereas the correct (& current) ad link is: https://SITE/adserver/www/delivery/ck.
×
×
  • Create New...