使用 Sinatra 获取 Facebooksigned_request
我试图弄清楚用户是否喜欢我们的品牌页面。基于此,我们想要显示一个“赞”按钮或一些“谢谢”文本。
我正在使用 Heroku 上托管的 sinatra 应用程序。
我尝试了此线程中的代码:Decoding Facebook'ssigned request in Ruby/Sinatra
但是,它似乎没有抓住signed_request,我不明白为什么。
我有以下方法:
get "/tab" do
@encoded_request = params[:signed_request]
@json_request = decode_data(@encoded_request)
@signed_request = Crack::JSON.parse(@json_request)
erb :index
end
# used by Canvas apps - redirect the POST to be a regular GET
post "/tab" do
@encoded_request = params[:signed_request]
@json_request = decode_data(@encoded_request)
@signed_request = Crack::JSON.parse(@json_request)
redirect '/tab'
end
我也有来自该线程的帮助消息,因为它们对我来说似乎有意义:
helpers do
def base64_url_decode(payload)
encoded_str = payload.gsub('-','+').gsub('_','/')
encoded_str += '=' while !(encoded_str.size % 4).zero?
Base64.decode64(encoded_str)
end
def decode_data(signed_request)
payload = signed_request.split('.')
data = base64_url_decode(payload)
end
end
但是,当我只是这样做
@encoded_request = params[:signed_request]
并在我的视图中读出它时:
<%= @encoded_request %>
我什么也得不到。
这不应该至少返回一些东西吗?我的应用程序似乎崩溃了,因为没有什么可以解码的。
我似乎无法在互联网上找到很多有关此问题的信息,因此如果有人可以帮助我,我会很高兴。
有没有更好的方法来了解用户是否喜欢我们的页面?或者,这是要走的路吗?我只是忽略了一些明显的事情吗?
谢谢!
I'm trying to figure out whether or not a user likes our brand page. Based off of that, we want to show either a like button or some 'thank you' text.
I'm working with a sinatra application hosted on heroku.
I tried the code from this thread: Decoding Facebook's signed request in Ruby/Sinatra
However, it doesn't seem to grab the signed_request and I can't figure out why.
I have the following methods:
get "/tab" do
@encoded_request = params[:signed_request]
@json_request = decode_data(@encoded_request)
@signed_request = Crack::JSON.parse(@json_request)
erb :index
end
# used by Canvas apps - redirect the POST to be a regular GET
post "/tab" do
@encoded_request = params[:signed_request]
@json_request = decode_data(@encoded_request)
@signed_request = Crack::JSON.parse(@json_request)
redirect '/tab'
end
I also have the helper messages from that thread, as they seem to make sense to me:
helpers do
def base64_url_decode(payload)
encoded_str = payload.gsub('-','+').gsub('_','/')
encoded_str += '=' while !(encoded_str.size % 4).zero?
Base64.decode64(encoded_str)
end
def decode_data(signed_request)
payload = signed_request.split('.')
data = base64_url_decode(payload)
end
end
However, when I just do
@encoded_request = params[:signed_request]
and read that out in my view with:
<%= @encoded_request %>
I get nothing at all.
Shouldn't this return at least something? My app seems to be crashing because well, there's nothing to be decoded.
I can't seem to find a lot of information about this around the internet so I'd be glad if someone could help me out.
Are there better ways to know whether or not a user likes our page? Or, is this the way to go and am I just overlooking something obvious?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
提示应该是您的应用程序崩溃,因为没有任何内容可解码。
我怀疑重定向时参数丢失。在 HTTP 级别考虑一下:
/tab
。/tab
,即发送带有代码 302(或类似)的响应以及指向/tab
的Location
标头。这完成了请求/响应周期,并且实例变量被丢弃。/tab
进行 GET。由于重定向的工作方式,这将不再具有与原始 POST 一起发送的参数。最简单的解决方案是仅渲染模板以响应 POST,而不是重定向。
如果您确实需要重定向,则需要小心地将signed_request作为重定向路径中的查询参数传递。至少这是我过去使用过的解决方案。可能有更简单的方法来解决这个问题,或者有一些库可以为您处理其中的一些问题。
The hint should be in your app crashing because there's nothing to decode.
I suspect the parameters get lost when redirecting. Think about it at the HTTP level:
/tab
with the signed_request in the params./tab
, i.e. sends a response with code 302 (or similar) and aLocation
header pointing to/tab
. This completes the request/response cycle and the instance variables get discarded./tab
. Because of the way redirects work, this will no longer have the params that were sent with the original POST.The simplest solution would be to just render the template in response to the POST instead of redirecting.
If you really need to redirect, you need to carefully pass along the signed_request as query parameters in the redirect path. At least that's a solution I've used in the past. There may be simpler ways to solve this, or libraries that handle some of this for you.