在调试器中缓存 OG 数据,强制 og:type 网站,并弹出授权“查看我们的抓取工具在您的 URL 中看到的内容”困境

发布于 2024-12-22 10:43:42 字数 989 浏览 1 评论 0原文

使时间轴正常工作时遇到问题。这是一个由两部分组成的问题。

首先,存在缓存 OG 元标记部分的问题。当调试器转到我的 URL 时,我知道它正确命中它,因为它返回的 og:url 是正确的,这意味着它已在我这边处理(例如:我将其发送到 og.php?og=read&chapter =799,它会返回 og:url 的正确 book_id,这意味着我的脚本处理了它)。但所有其他信息似乎都被缓存了。我最初错误地为一个对象设置了 fb:app_id 和 og:site_url ,所以我删除了它们。输出仍然显示那些现有的 site_url 会引发错误。拥有 fb:app_id 会强制使用“网站”的 og:type,我已(正确)将其设置为我的命名空间和对象。当我尝试 POST 操作时,收到 oAuthException 错误,表明 og:type 的“网站”对于对象无效。再次强调,这个问题应该得到解决,但它会继续缓存旧的 OG 数据。我尝试添加 ?fbrefresh=1,但这没有任何作用。

另一个问题,可能相关......即使我知道它到达那里,并且我的脚本处理了请求,Facebook 也没有报告这一点。当我点击“准确查看我们的抓取工具在您的 URL 中看到的内容”时,它会显示身份验证 URL(见下文)!就好像它从未到达那里并且启动了弹出窗口,这甚至不是 og.php 代码的工作方式!我的猜测是,他们在尝试使用 example.com/og.php 发出完整请求之前,从基本域名本身 (exmaple.com) 获取了该信息。

window.parent.location='https://www.facebook.com/dialog/oauth?client_id=164431733642252&redirect_uri=http%3A%2F%2Fapps.facebook.com%2Fexamp le%2F%3Fpage%3D&state=064bd26ff582a9ec7c96729e6b69bbd2&canvas=1&fbconnect=0&scope=email%2Cpublish_stream%2Cpublish_actions%2C';

Having issues getting Timeline to work. It is a two part problem.

First, there is an issue of caching parts of the OG metatags. When the debugger goes to my URL, I know it is hitting it correctly because the og:url it spits back is correct which means it has been processed on my end (ex: I send it to og.php?og=read&chapter=799, and it will spit back the right book_id for the og:url, meaning my script processed it). But all the other information seems to be cached. I originally and erroneously had an fb:app_id and og:site_url for an object, so I removed those. The output still shows those as having an existing site_url which is throwing an error. Having a fb:app_id forces the og:type of 'website', which I have set (correctly) to my namespace and object. When I try to POST the action, I get an oAuthException error back, that an og:type of 'website' isn't valid for an object. Once again, that should be fixed, but it keeps caching the old OG data. I have tried adding ?fbrefresh=1, but that did nothing.

Another issue, possibly related...even though I know it got there, and my script processed the request, Facebook doesn't report that. When I click on "See exactly what our scraper sees for your URL" it shows the authentication URL (see below)! As though, it never got there and the popup was initiated, which isn't even how the code for og.php works!! My guess is they got that from the base domain name itself (exmaple.com) before trying the full request with example.com/og.php.

window.parent.location='https://www.facebook.com/dialog/oauth?client_id=164431733642252&redirect_uri=http%3A%2F%2Fapps.facebook.com%2Fexample%2F%3Fpage%3D&state=064bd26ff582a9ec7c96729e6b69bbd2&canvas=1&fbconnect=0&scope=email%2Cpublish_stream%2Cpublish_actions%2C';

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

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

发布评论

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

评论(2

梦里人 2024-12-29 10:43:42

我想通了。我认为 og:url 是您希望人们用来访问应用程序中正确页面的 URL,例如操作链接。是的,但事实并非如此。我现在让它与您发送到时间线的 OBJECT_URL 相匹配。

我有一个不同的 URL(指向应用程序的操作链接),当重定向时,爬虫程序无法访问该 URL,因为它位于应用程序授权墙内。这导致 og: 网站类型和数据显示为已缓存。

为了解决这个问题,我发布到时间线的 object_url 和元标记中的 og:url 是相同的。但是您可以通过查找从时间轴上的链接发送的查询字符串:?fb_action_ids=SOME_ID 来确定它是爬虫还是操作链接。如果它包含该内容,那么我会将其转发到那里所需的应用程序页面。

I figured it out. I thought the og:url was the URL you wanted people to use to get to the correct page in your app, like an action link. It is, but it isn't. I now have it match the OBJECT_URL you send to timeline.

I had a different URL (an action link to the app), which when redirected, can't be reached by the crawler because it is inside the applications authorized wall. This caused the og:type of website, and data to appear cached.

To fix it, the object_url I post to timeline, and the og:url in the metatag is the same. But you can figure out if it is the crawler or the action link by looking for the query string: ?fb_action_ids=SOME_ID which is sent from link on the timeline. If it contains that, then I forward it to the application page needed from there.

荒路情人 2024-12-29 10:43:42

我也有和你类似的问题。它一直抱怨 og:site_url 被设置,即使我从未设置过这些。看起来它发送的错误消息实际上是不准确的,问题不在于 og:site_url 被设置,而在于 og:url 与对象 url 不同。有时,错误的错误消息比没有错误消息更糟糕!

另一个问题是为什么对象 url 必须对应于用户将看到的实时页面。对象是一个逻辑单元,但它不一定对应于单个用户可见的页面。您的重定向技巧可能会起作用,但这不是做某事的正确方法。当我发布与对象相关的操作时,应该使用对象 url 来绘制该对象的信息,但我应该能够将用户发送到其他地方。如果这是有意的设计,我认为这是一个错误。

I'm having similar problems to you. It kept complaining about og:site_url being set, even though I never set those. It appears that the error messages it sends are actually inaccurate, and the problem is not that og:site_url is being set, but that the og:url is different from the object url. Sometimes a wrong error message is worse than no error message!

A further question is why an object url has to correspond to a live page that a user will see. An object is a logical unit, but it doesn't necessarily correspond to a single user-visible page. Your redirection trick might work, but it is not the proper way to do something. When I post an action related to an obect, the object url should be used to draw the information of the object, but I should be able to send the user somewhere else. If this was an intended design I think it is a mistake.

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