通过 https 在 iframe 中加载页面应用程序时静默失败
问题
我有一个应用程序驱动客户端页面上的选项卡。如果用户未启用 FB 的“安全浏览”功能，则应用程序可以正常运行。如果尝试通过 HTTPS 查看，iframe 甚至不会出现（没有错误，没有混合内容警告）。当通过 HTTP 正确加载时，ID 为“pagelet_app_runner”的 div 会插入一个 iframe，并且应用程序内容会加载到其中。通过 HTTPS，此 div 保持为空，并且 iframe 不会插入到页面中。 Firebug 或 Chrome 的等效控制台中没有出现 Javascript 错误。
为什么我在这里提问
主机拥有有效的 SSL 证书，并且相关 URL 中不存在“混合内容”。我可以通过直接访问 URL 成功查看 HTTP 或 HTTPS 内容，也可以通过访问 apps.facebook.com/canvasURL/tabURL 执行相同操作。仅当尝试在页面选项卡内查看时，HTTPS 加载才会失败，如上所述。我的应用程序配置了常规和安全的画布和选项卡 URL。
尝试调试
我已经记录了与 Charles 的一些会话，但由于 iframe 没有插入到页面中，我想我是在问题已经发生后才遇到这个问题的。我不是查尔斯专家，所以很高兴在这里得到纠正。
Apache 没有看到任何受影响负载的请求（无论是常规日志还是 ssl 日志）。非 SSL 加载按 access_log 中的预期进行。
请求帮助
我没有办法调试这个。有人有什么建议吗？我可能犯了什么明显而愚蠢的错误？ :)
编辑：更好的格式
Problem
I have an application driving a tab on a client's page. The application works correctly if the user has not enabled FB's "secure browsing" feature. If attempting to view over HTTPS, the iframe doesn't even appear (no errors, no mixed-content warnings). When correctly loading over HTTP, the div with the id "pagelet_app_runner" has an iframe inserted into it and the application content is loaded inside there. Over HTTPS, this div remains empty and the iframe is not inserted into the page. There are no Javascript errors appearing in Firebug or Chrome's equivalent console.
Why I'm Asking Here
The host has a valid SSL certificate and there is no 'mixed content' at the URL in question. I can successfully view the content over HTTP or HTTPS by visiting the URL directly, and I can do the same by visiting apps.facebook.com/canvasURL/tabURL. It is only when attempting to view within a Page Tab that the HTTPS load fails as described above. My application is configured with both regular and secure canvas and tab URLs.
Attempted Debugging
I've recorded some sessions with Charles but since the iframe isn't being inserted into the page, I think I'm coming at the problem after it's already occured. I'm no Charles expert so happy to be corrected here.
Apache isn't seeing any request (in either regular or ssl logs) for the affected loads. non-SSL loads come through as expected in access_log.
Plea for Help
I'm out of ideas for debugging this. Does anybody have any suggestions? What really obvious and stupid mistake might I have made? :)
edit: nicer formatting
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的应用程序画布 URL 是
https://skinnycomp.nextstudio.com.au/skinnycowcomps/，它将 404 错误发送到 Facebook 代理（通过选项卡查看应用程序时，请求将通过代理），查看时也是如此您的应用程序通过应用程序（https://apps.facebook.com/122381834451561/），再次404...也许Facebook代理忽略404 并发布空白...尝试将画布 URL 更改为
https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab，您也可以在signed_request中检查您的应用是否通过页面选项卡访问应该有page_id...Your app canvas URL is
https://skinnycomp.nextstudio.com.au/skinnycowcomps/, which send 404 error to Facebook proxy (request is going through proxy when viewing app via tab), also when viewing your app via apps (https://apps.facebook.com/122381834451561/), again 404... maybe Facebook proxy is ignoring 404 and posting blank...Try changing canvas URL to
https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab, also you can check if your app is accessed via page tab, insigned_requestthere should bepage_id...这是一个真正的成功，因为我确信您已经三次检查了所有设置，但是如果在应用程序设置的“页面选项卡 URL”字段中指定了无效的 URL，则可能会出现空白页面。由于它仅发生在 https 上，因此它暗示了安全页面选项卡 URL 条目的特定内容。可能值得再次检查，甚至可能重新保存它或将其更改为其他内容，看看是否有帮助。
This is a real longshot since I'm sure you've triple checked all the settings, but the blank page can happen if an invalid url is specified in the Page Tab URL field in the app settings. Since it only happens on https, it would imply something specifically with the Secure Page Tab URL entry. It might be worth checking that again, and maybe even re-saving it or changing it to something else to see if it helps.
我在常规和安全选项卡 URL 字段中使用相对 URL。根据记忆，这里的相对 URL 在过去的某个时候是强制性的。现在看来，相对 URL 仍然适用于 HTTP，但不适用于 HTTP。修复：绝对 URL。希望 FB 更新他们的现场验证以符合要求。
I was using relative URLs for the regular and secure tab URL fields. From memory relative URLs here were mandatory at some point in the past. It appears now that a relative URL will still work for HTTP but not for HTTPs. Fix: absolute URLs. Hopefully FB update their field validation to match what's required too.