防止从浏览器到应用商店的不必要的重定向 [英] Preventing unwanted redirects from browser to app store

查看:270
本文介绍了防止从浏览器到应用商店的不必要的重定向的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在研究广告和应用商店之间的重定向页面.广告以指向重定向页面的静态URL的形式存在.重定向页面将ajax请求发送给第三方,设置cookie,然后重定向到AppStore.一切都很好,也不少见.

I've been working on a redirect page that sits between an ad and the app store. The ad exists as a static URL that directs to the redirect page. The redirect page sends an ajax request to a third party, sets a cookie, then redirects to the AppStore. All well and good and not uncommon.

重定向页面无法自行关闭,因此它仍作为Safari中的选项卡.我遇到的问题是,如果从缓存中清除了页面,则当用户返回Safari时,Safari会重新加载页面以触发重定向.我不希望用户意外进入AppStore.

The redirect page cannot close itself so it remains as a tab in Safari. The issue I'm having is that when the user returns to Safari if the page is been purged from the cache, Safari will reload it triggering the redirect. I do not want the users getting thrown into the AppStore unexpectedly.

一种解决方案是检查cookie是否存在,如果存在,则不进行重定向,但这使用户单击另一个横幅广告并没有获得适当的重定向时处于边缘情况.我尝试将锚添加到URL上以防止用户启动刷新,但是Safari的自动刷新机制不遵守以编程方式添加的哈希.

One solution would be to check for the presence of a cookie and not redirect if it's presence, but this leaves the edge case of the user clicking on another banner ad and not getting the appropriate redirect. I've tried appending an anchor to the URL which prevents user initiated refreshes, but the auto-refresh mechanism of Safari does not respect the programmatically added hash.

如果我可以使用动态源生成将用户定向到页面的URL,则可以生成时间戳,但是现在原始URL是静态的.有没有人使用客户端代码来解决这个问题?还是仅使用服务器端解决方案才可以解决?

If I could use a dynamic source to generate the URL that directs the user to the page I could generate a timestamp, but right now the origin URL is static. Does anyone have a solution for this using client side code? Or is this really only solvable using a server-side solution?

推荐答案

我最终选择进行两阶段重定向.用户单击横幅,然后定向到:

I ended up choosing to do a two stage redirect. User clicks a banner and gets directed to:

http://myserver.example.com?someKey=someValue

我有一个执行此操作的功能:

I have a function that does this:

// Do I have a visited param?
if ($.url(window.location.href).param('visited') === '1') {
    // Do I have a visited cookie?
    if (helper.retrieveCookie('VISITED') == undefined) {
        console.log('Setting visited cookie');
        helper.storeCookie('VISITED', '1');
        return 1; // Redirect to AppStore.
    }
    // Have param and cookie
    console.log('VISITED cookie set');
    console.log('Refreshed');
    return 2; // Don't redirect.
} else {
    // No param
    helper.removeCookie('VISITED');
    return 0; // Redirect to self with &visited=1
}

因此,基本上,我们将有意义地两次遍历代码,随后由于刷新而将N次遍历.在第一遍中,我们执行AJAX请求,然后使用添加的参数重定向到我们自己.在第二遍过程中,我们设置一个cookie并重定向到AppStore.页面的任何后续加载将同时具有cookie和参数,并且不会重定向.新的横幅广告点击不会包含任何参数,因此它们会正常运行.

So basically we will pass through the code twice meaningfully and N times subsequently due to refreshes. During the first pass we do our AJAX request, then redirect to ourself with an added param. During the second pass we set a cookie and redirect to the AppStore. Any subsequent load of the page will have both a cookie and a param and won't redirect. New banner clicks will not have the param so they will perform normally.

这不是最漂亮的解决方案,因为我们必须重新加载重定向页面,但是由于应该缓存其内容,因此点击量应该很小.

This isn't the most beautiful solution since we have to reload our redirect page, but since its contents should be cached, the hit should be minimal.

这篇关于防止从浏览器到应用商店的不必要的重定向的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆