iFrame在Facebook Canvas App中显示空白 [英] iFrame showing up Blank in Facebook Canvas App

查看:216
本文介绍了iFrame在Facebook Canvas App中显示空白的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个非常简单的页面,我想在Facebook的iframe中查看。这是一个Django视图,但它不依赖于请求是通过POST还是GET来提交的。它所做的只是返回一些简单的HTML。



如果我们直接点击链接,它会正确显示。如果在firefox中,我右键单击iframe,然后选择仅显示该框架的选项,然后正确显示。但是,当查看Facebook应用程序时,没有任何显示。



这是App Link: http://apps.facebook.com/fireflietest/
哪些指向 http://www.fireflie.com/facebook/



这是我非常简单的视图的代码:

  from django.http import HttpResponse 
from django.views.decorators.csrf import csrf_exempt,csrf_protect

@csrf_exempt
def facebook(request):
body =
< html>
< head>< title> Facebook上的Fireflie< / title>< / head>
< body>您好,Facebook!< / body>
< / html>

返回HttpResponse(body)

只是为了测试目的,我创建了一个小的HTML表单,将POST到该页面。工作正常我也运行了Facebook调试工具,scraper显示它正确地拉我们的内容。



这是服务器日志,显示它返回200 OK两次:

  24.210.144.32  -   -  [15 / Jun / 2012:18:27:18 +0000]POST / facebook / HTTP /1.1200 31http://apps.facebook.com/fireflietest/Mozilla / 5.0(X11; Linux x86_64)AppleWebKit / 535.19(KHTML,像Gecko)Ubuntu / 12.04 Chromium / 18.0.1025.151 Chrome / 18.0。 1025.151 Safari / 535.19

24.210.144.32 - - [15 / Jun / 2012:18:27:26 +0000]GET / facebook / HTTP / 1.1200 67 - Mozilla / 5.0(X11; Linux x86_64)AppleWebKit / 535.19(KHTML,像Gecko)Ubuntu / 12.04 Chromium / 18.0.1025.151 Chrome / 18.0.1025.151 Safari / 535.19

最后,我尝试使用Chrome的开发人员工具挖掘响应对象,但在查看iframe版本时,看起来就像返回的所有内容都是内容标题。

有没有人有任何想法,

这里发生了什么?还是任何关于如何进一步调试这个问题的想法?谢谢。



编辑:我将Facebook应用程序的URL复制并粘贴到同一个地方。我会再次复制它,以防万一我做错了。我不知道为什么会抛出一个404。



从地址栏直接复制并粘贴: http://apps.facebook.com/fireflietest/



更新:原来我不得不转过沙盒模式。不应该再有404.当然,我仍然遇到原来的问题,我的iFrame显示为空。谢谢!



更新2:(从Django用户组中复制并粘贴thead)


$ b $我一直在试图诊断这个问题。我不知道发生了什么事。


  1. 我只是在Nginx上提供一个简单的.html页面,看看是否问题在哪里。它无法正常运行(通过错误),但确实显示错误。问题在于,您无法在NGINX中的静态页面上POST。没有什么大不了的,我不想加载静态页面。


  2. 我查看了我的日志文件。事实证明,我的应用程序是超时的。它没有任何意义,因为它不会在任何其他地方超时。


  3. 这里有一些显示出奇特的日志。我不知道如何调试问题。从我正在阅读的 - 这是我的照片正在发生。


Nginx正确接收请求。 Nginx将请求提交给uWSGI应用程序(django)。 Django成功获取请求。 Django尝试回应,但这必须是它所在的地方。



我不知道问题是什么 - 但它与Facebook的iframe有关。 (我还没有检查一般的远程iframe,下一步会做)

  uWSGI日志:
[ pid:11059 | app:0 | req:3/4] 24.210.144.32(){527在1170字节中的变量} [Tue Jun 19 14:24:03 2012] POST / facebook / =>在444毫秒(HTTP / 1.1 500)中生成0个字节0个字节中的0个标题(0个内核0的开关)
[pid:11345 | app:0 | req:1/1] 24.210.144.32(){52 1170字节中的变量} [Tue Jun 19 14:24:31 2012] POST / facebook / =>在333毫秒(HTTP / 1.1 200)中生成2970字节(HTTP / 1.1 200)128个字节的4个标题(1个内核0的开关)
[pid:11353 | app:0 | req:3/31] 24.210.144.32(){52 vars in 1172 bytes} [Tue Jun 19 14:31:04 2012] POST / facebook / =>在3毫秒(HTTP / 1.1 200)中生成2970字节(HTTP / 1.1 200)128个字节的4个标头(1个内核0个开关)
[pid:11954 | app:0 | req:1/14] 24.210.144.32(){52 1216字节的变量} [Tue Jun 19 14:35:04 2012] POST / facebook / =>在343毫秒(HTTP / 1.1 200)中生成2970字节(HTTP / 1.1 200)128个字节的4个标头(1个内核0的开关)
[pid:11950 | app:0 | req:2/31] 24.210.144.32(){52 1211字节中的vars} [Tue Jun 19 14:48:57 2012] POST / facebook / =>在3毫秒(HTTP / 1.1 200)中生成2970字节(HTTP / 1.1 200)128个字节的4个标题(1个内核0的开关)
[pid:11962 | app:0 | req:4/57] 24.210.144.32(){52 1216字节中的变量} [Tue Jun 19 14:53:43 2012] POST / facebook / =>在2毫秒内生成2970字节(HTTP / 1.1 200)128个字节的4个标题(1个内核0个开关)

Nginx错误日志:
2012/06/19 20:02:30客户端:24.210.144.32,服务器:fireflie.com请求:POST / facebook / HTTP / 1.1,上游的(错误)11164#0:* 29617 readv() :uwsgi://< commented out for security>,host:www.fireflie.com,referrer:http://apps.facebook.com/253156011452899/

Nginx访问日志:
24.210.144.32 - - [19 / Jun / 2012:20:02:30 +0000]POST / facebook / HTTP / 1.1200 31http://apps.facebook.com/253156011452899 /Mozilla / 5.0(X11; Linux x86_64)AppleWebKit / 535.19(KHTML,像Gecko)Ubuntu / 12.04 Chromium / 18.0.1025.151 Chrome / 18.0.1025.151 Safari / 535.19
24.210.144.32 - - [19 / 2012年6月20日20:03:29 +0000] - 408 0 - -
24.210.144.32 - - [19 / 408 0 - -


解决方案

溶液



问题在于uWSGI。我不知道为什么它不工作 - 但我相信这可能是与Facebook的Canvas应用程序POST的太小的数据。无论如何,这里的修复对我有用。



我修改了我的uWSGI配置选项。我添加了以下三个选项,即使第一个可能是一个no-op,最后一个可能只是在那里有良好的安全性(它在我的分期站点没有它)。

 < pep3333输入/> 
< post-buffered> 4096< / post-buffered>
< buffer-size> 32768< / buffer-size>


I have an extremely simple page that I'm trying to view in the Facebook iframe. It's a Django-view but it's not dependent upon whether the request is submitted via POST or GET. All it does is returns some simple HTML.

If we hit the link directly, it displays correctly. If, in firefox, I right-click on the iframe and choose the option to display only that frame -- then it shows correctly. However, when viewing the Facebook App, nothing shows up.

Here's the App Link: http://apps.facebook.com/fireflietest/ Which points to http://www.fireflie.com/facebook/

Here's the code for my very simple view:

from django.http import HttpResponse
from django.views.decorators.csrf import csrf_exempt, csrf_protect

@csrf_exempt
def facebook(request):
    body = """
    <html>
        <head><title>Fireflie on Facebook</title></head>
        <body>Hello, Facebook!</body>
    </html>
    """
    return HttpResponse(body)

Just for testing purposes, I created a small HTML form that would POST to that page. It works fine. I also ran the Facebook debugging tool and the "scraper" showed that it's pulling our content correctly.

Here's the server logs showing that it is returning a 200 OK both times:

24.210.144.32 - - [15/Jun/2012:18:27:18 +0000] "POST /facebook/ HTTP/1.1" 200 31 "http://apps.facebook.com/fireflietest/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19"

24.210.144.32 - - [15/Jun/2012:18:27:26 +0000] "GET /facebook/ HTTP/1.1" 200 67 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19"

Finally, I tried digging into the response object using Chrome's developer tools but it looks like all that is being returned, when viewing the iframe version, is the content headers.

Does anybody have any idea on what's going on here? Or any ideas on how to futher debug this problem? Thanks.

Edit: I copied and pasted the Facebook App's URL into the same spot. I'm going to duplicate it here again just in case I did something wrong. I'm not sure why it was throwing a 404.

Copied and pasted straight from the address bar: http://apps.facebook.com/fireflietest/

Update: Turns out I had to turn of Sandbox mode. There shouldn't be any more 404. Of course, I'm still running into the original problem which is my iFrame showing up empty. Thanks!

Update 2: (Copied & Pasted from my Django User Group thead)

I've been trying to diagnose this problem. I have no idea what's going on, though.

  1. I tried just serving a simple .html page on Nginx to see if that's where the problem was. It didn't serve properly (through an error) but it did actually display the error. The problem there was, you can't POST to static pages in NGINX. No big deal, I'm not trying to load a static page anyways.

  2. I looked in my log files. It turns out, my application is timing out. It doesn't make any sense as it doesn't timeout anywhere else.

  3. Here's some logs that show something peculiar going on. I'm not sure how to debug the issue. From what I am reading though -- here's what I picture is going on.

Nginx properly receives request. Nginx pushes request to uWSGI application (django). Django successfully gets the request. Django tries to respond but this must be where it breaks.

I'm not sure what the issue is -- but it has something to do with being inside a facebook iframe. (I have yet to check remote iframes in general, I'll do that next)

uWSGI Logs:
[pid: 11059|app: 0|req: 3/4] 24.210.144.32 () {52 vars in 1170 bytes} [Tue Jun 19            14:24:03 2012] POST /facebook/ => generated 0 bytes in 444 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)
[pid: 11345|app: 0|req: 1/1] 24.210.144.32 () {52 vars in 1170 bytes} [Tue Jun 19 14:24:31 2012] POST /facebook/ => generated 2970 bytes in 333 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11353|app: 0|req: 3/31] 24.210.144.32 () {52 vars in 1172 bytes} [Tue Jun 19 14:31:04 2012] POST /facebook/ => generated 2970 bytes in 3 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11954|app: 0|req: 1/14] 24.210.144.32 () {52 vars in 1216 bytes} [Tue Jun 19 14:35:04 2012] POST /facebook/ => generated 2970 bytes in 343 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11950|app: 0|req: 2/31] 24.210.144.32 () {52 vars in 1211 bytes} [Tue Jun 19 14:48:57 2012] POST /facebook/ => generated 2970 bytes in 3 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11962|app: 0|req: 4/57] 24.210.144.32 () {52 vars in 1216 bytes} [Tue Jun 19 14:53:43 2012] POST /facebook/ => generated 2970 bytes in 2 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)

Nginx Error Logs:
2012/06/19 20:02:30 [error] 11164#0: *29617 readv() failed (104: Connection reset by peer) while reading upstream, client: 24.210.144.32, server: fireflie.com, request: "POST /facebook/ HTTP/1.1", upstream: "uwsgi://<commented out for security>", host:     "www.fireflie.com", referrer: "http://apps.facebook.com/253156011452899/"

Nginx Access Log:
24.210.144.32 - - [19/Jun/2012:20:02:30 +0000] "POST /facebook/ HTTP/1.1" 200 31 "http://apps.facebook.com/253156011452899/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19"
24.210.144.32 - - [19/Jun/2012:20:03:29 +0000] "-" 408 0 "-" "-"
24.210.144.32 - - [19/Jun/2012:20:03:29 +0000] "-" 408 0 "-" "-"

解决方案

Solution

The problem was with uWSGI. I'm not exactly sure why it wasn't working -- but I believe it might have been something to do with Facebook's Canvas App POSTing too small of data. Anyways, here's the fix that worked for me.

I modified my uWSGI configuration options. I added the following three options even though the first might be a no-op and the last is probably just there for good safety (it works on my staging site without it).

<pep3333-input/>
<post-buffering>4096</post-buffering>
<buffer-size>32768</buffer-size>

这篇关于iFrame在Facebook Canvas App中显示空白的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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