使用 Pusherapp 的私人频道（使用 Rails）

发布于 2024-10-18 14:04:24 字数 940 浏览 4 评论 0原文

我刚刚完成了 Pusherapp 的hello world。现在我想创建私人频道，以便用户只阅读他们应该阅读的消息。

Pusher 文档仅提供了有关如何执行此操作的一些详细信息，我有点迷失了。

来自文档：

... 返回 Pusher JS 库连接时的socket_id 推手。
当它尝试订阅私人频道，它发回一个 AJAX 向您的服务器请求 Channel_name 和 socket_id 为参数。
默认 URL 是 http://yourserver.com/pusher/auth。 ...

class PusherController < ApplicationController
  def auth
    if current_user
      response = Pusher[params[:channel_name]].authenticate(params[:socket_id])
      render :json => response
    else
      render :text => "Not authorized", :status => '403'
    end
  end
end

给定一个唯一的用户 ID (current_user.id)，我如何验证该用户然后让他/她订阅相应的频道？

谢谢

原文

I just got through the hello world for Pusherapp. Now I want to create private channels so users only read messages that they are supposed to read.

The Pusher docs only give some details on how to do this, and I'm kind of lost.

From the docs:

...
The Pusher JS library is returned
a socket_id when it connects to
Pusher.
When it attempts to subscribe to a
private channel, it sends back an AJAX
request to your server with the
channel_name and socket_id as
parameters.
The default URL for this is
http://yourserver.com/pusher/auth.
...

class PusherController < ApplicationController
  def auth
    if current_user
      response = Pusher[params[:channel_name]].authenticate(params[:socket_id])
      render :json => response
    else
      render :text => "Not authorized", :status => '403'
    end
  end
end

Given a unique user id (current_user.id), how can I authenticate that user then have him/her subscribe to the corresponding channel?

Thanks

分享到QQ

分享到微博

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

发布评论

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

挽手叙旧 2024-10-25 14:04:24

这篇关于实现的博客文章似乎对事情做了更多解释： https://pusher.com/docs/ client_api_guide/client_private_channels

授权方案基于
这个想法，而不是
实施自定义用户
身份验证，并增加复杂性
并对推动者说，我们应该相信
现有的身份验证级别
由您的应用程序提供。我们也
想要确保有人阅读
从您的应用程序发送到的数据
浏览器无法连接
作为该用户访问某个频道，以及
因此不能包含任何秘密
在页面 HTML 中。

听起来您的应用程序的业务逻辑应该对用户进行身份验证并决定他们应该访问专用通道。

他们的图表显示：

在此处输入图像描述

经过身份验证后，应用程序会请求订阅用户。 Pusher 使用 socket_id 进行回复。然后他们用它连接起来。

他们是这样描述的：

如图所示，一个独特的
生成套接字 id 并将其发送到
Pusher 的浏览器。此信息发送至
您的应用程序 (1) 通过 AJAX
授权用户的请求
访问针对您的频道
现有的认证系统。如果
成功您的申请会返回
浏览器的授权字符串
与你签署的 Pusher 秘密。这是
通过 WebSocket 发送到 Pusher，
至此完成授权(2)
如果授权字符串匹配。

博客文章底部的示例进一步说明了：

假设您有一个名为 project-3 的频道，用户 A 和 B 可以访问该频道，但不能访问 C。您希望将此频道设为私有，以便用户 C 无法收听参加私人活动。只需将事件发送到 private-project-3 并在浏览器中订阅它即可。只要您使用最新的 javascript（版本 1.3 或更高版本），您就会看到向您的应用程序发出了一个发送到 /pusher/auth 的 POST 请求。目前这将失败，因此不会向套接字发出订阅请求。

所以，对我来说，这听起来像：
1）订阅请求发送给Pusher
2) Pusher POST 到您的 /auth 方法以确定用户是否可以访问该频道
3）如果您的业务逻辑允许用户访问此通道，则 auth 方法将返回“ok”响应：

auth = Pusher[params[:channel_name]].socket_auth(params[:socket_id])

    content_type 'application/json'
    return JSON.generate({
      :auth => auth
    })

我没有使用 Pusher 本身，但它的模型似乎反映了其他基于推送的模型的结构。希望这有帮助！

This blog post on the implementation seems to explain things a bit more: https://pusher.com/docs/client_api_guide/client_private_channels

The authorization scheme is based on
the idea that, rather than
implementing custom user
authentication, and adding complexity
and state to pusher, we should trust
the existing level of authentication
offered by your application. We also
wanted to ensure that someone reading
data sent from your application to the
browser would not be able to connect
to a channel as that user, and
therefore couldn't include any secrets
in the page HTML.

Sounds like your application's business logic should authenticate the user and decide that they should access the private channel.

Their diagram shows:

enter image description here

Once authenticated, the app requests to subscribe the user. Pusher replies with the socket_id. Then they are connected using that.

Here's how they describe it:

As shown in this diagram, a unique
socket id is generated and sent to the
browser by Pusher. This is sent to
your application (1) via an AJAX
request which authorizes the user to
access the channel against your
existing authentication system. If
successful your application returns an
authorization string to the browser
signed with you Pusher secret. This is
sent to Pusher over the WebSocket,
which completes the authorization (2)
if the authorization string matches.

The example at the bottom of the blog post further clarifies:

Suppose you have a channel called project-3, to which users A and B have access, but not C. You'd like to make this channel private so that user C cannot listen in on the private events. Simply send events to private-project-3 and subscribe to it in the browser. As long as you're using the latest javascript (version 1.3 or above), you'll see that a POST request is made to your application to /pusher/auth. This will currently fail, and therefore the subscribe request will not be made to the socket.

So, to me this sounds like:
1) Request to subscribe is sent to Pusher
2) Pusher POSTs to your /auth method to determine if the user can access the channel
3) If your business logic allows the user to access this channel, the auth method returns the "ok" response:

auth = Pusher[params[:channel_name]].socket_auth(params[:socket_id])

    content_type 'application/json'
    return JSON.generate({
      :auth => auth
    })

I haven't used Pusher itself, but its model seems to mirror the structure of other push-based models. Hope this helps!

回复收藏 0 原文

~没有更多了~