如何处理 OpenX XMLRPC 身份验证/会话

发布于 2024-07-19 07:18:23 字数 447 浏览 10 评论 0原文

我在使用 Openx 时遇到问题; 这是问题

OpenX::Services::Base.connection 返回类变量 @@connection,如果之前尚未初始化,则该类变量由 OpenX::Services::Base.connection 填充。

它作为一个类变量的问题在于它在连接之间持续存在,这意味着如果活动暂停,我的站点和 OpenX 之间的 XMLRPC 会话将超时,并且 OpenX API 没有用于通信过期会话的规定,无论如何,这都是浪费的,因为在每次通信之前都需要发出请求来验证会话是否仍然有效。

我认为更好的方法是在任何需要 OpenX 支持的请求开始时实例化一个连接,并在结束时关闭它,确保在网络上不存在会话超时的可能性。 XMLRPC 方面的事情。

有其他人在使用 OpenX / OpenX XMLRPC 时遇到过这种情况吗? 如果是这样,您是如何解决这个问题的?

I am having trouble with Openx; here is the issue

OpenX::Services::Base.connection returns the class variable @@connection which is populated by OpenX::Services::Base.connection if it has previously not been initialized.

The problem with it being a class variable is that it persists across connections, which means if there is a lull in activity, the XMLRPC session between my site and OpenX will time out, and the OpenX API has no provisions for communicating an expired session, which would be wasteful anyways as it would require a request before every communication just to verify that the session was still valid.

What I think would be a better way to do it would be to instantiate a connection at the beginning of any request that needs OpenX support, and to close it at the end, ensuring that there is no possibility of a session time-out on the XMLRPC side of things.

Has anyone else encounted this when using OpenX / OpenX XMLRPC? If so how did you resolve this issue?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

这样的小城市 2024-07-26 07:18:23

我在 OpenX RPC 调用周围有一个 try/catch 块,并且编写了一个异常转换器。 如果我检测到会话超时,我将再次执行登录操作,我将获取新的会话 ID,并再次运行失败的 OpenX 调用。 它比使用 cron 作业稍微复杂一点,以保持会话处于活动状态,但性能更高、更健壮(在我看来)。

I have a try/catch block around the OpenX RPC call, and I wrote an exception translator. If I detect a session timeout I will execute a again the login operation, I will take the new session id and I will run the failed OpenX call again. It is a little bit more complicated than having a cron job in order to keep the session alive but more performant and robust (in my opinion).

我最亲爱的 2024-07-26 07:18:23

我们面临同样的问题。 我们的解决方案:创建一个未经身份验证的控制器,它与 OpenX API 进行一些简单的交互(只是为了使其保持活动状态),并让 cron 作业每 5-10 分钟调用此 URL。

您使用了什么解决方案?

We faced the same issue. Our solution: Create a unauthenticated controller which does some simple interactions with the OpenX API (just to keep it live) and have this URL invoked by a cron job every 5-10 min.

What solution did you use?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文