chaînes privées avec Pusherapp (en utilisant Rails)

Question

Je viens de recevoir par la hello world pour Pusherapp. Maintenant, je veux créer des chaînes privées afin que les utilisateurs lisent uniquement les messages qu'ils sont censés lire.

Le pousseur docs ne donnent que quelques détails sur la façon de le faire, et je suis un peu perdu.

De l'docs:

... La bibliothèque Pusher JS est retourné un socket_id quand il se connecte à Pusher.

Quand il tente de souscrire à un canal privé , il renvoie une requête AJAX à votre serveur avec le channel_name et socket_id comme paramètres. L'URL par défaut est 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 

Étant donné un nom d'utilisateur unique (current_user.id), comment puis-je authentifier l'utilisateur puis demandez-lui/elle abonner à la chaîne correspondante?

Merci

Answer 1

Ce billet de blog sur la mise en œuvre semble expliquer les choses un peu plus: https://pusher.com/docs/client_api_guide/client_private_channels

Le régime d'autorisation est basée sur l'idée que, plutôt que implémentation de l'authentification utilisateur personnalisée , et en ajoutant de la complexité et de l'état pousseurs, nous devrions faire confiance le niveau actuel d'authentification offerte par votre application. Nous avons également voulu faire en sorte que quelqu'un lisant les données envoyées par votre application au navigateur ne serait pas capable de se connecter à un canal que cet utilisateur et ne pouvait donc pas inclure les secrets dans le code HTML de la page.

Cela ressemble à la logique métier de votre application qui doit authentifier l'utilisateur et décider qu'il doit accéder au canal privé.

Leur diagramme montre:

Une fois authentifiés, les demandes d'application pour vous abonner l'utilisateur. Pusher répond avec socket_id. Ensuite, ils sont connectés en utilisant cela.

Voilà comment ils le décrivent:

Comme le montre ce schéma, un identifiant de prise unique est généré et envoyé au navigateur par Pusher.Ceci est envoyé à votre demande (1) via une requête AJAX qui autorise l'utilisateur à accéder au canal par rapport à votre système d'authentification existant . Si réussi votre application renvoie une chaîne d'autorisation au navigateur signé avec vous Pusher secret. C'est envoyé à Pusher sur le WebSocket, qui complète l'autorisation (2) si la chaîne d'autorisation correspond.

L'exemple au bas du billet de blog plus précise:

Supposons que vous ayez un canal appelé projet-3, à laquelle les utilisateurs A et B ont accès, mais pas C. Vous aimeriez rendre ce canal privé afin que l'utilisateur C ne puisse pas écouter les événements privés. Il suffit d'envoyer des événements à private-project-3 et de s'y abonner dans le navigateur. Tant que vous utilisez le dernier javascript (version 1.3 ou supérieure), vous verrez qu'une requête POST est envoyée à votre application vers/pusher/auth. Cela va actuellement échouer, et donc la demande d'abonnement ne sera pas faite à la socket.

Donc, pour moi cela ressemble à: 1) Demande de souscription est envoyé à Pusher 2) Pusher POSTs à votre/méthode d'authentification pour déterminer si l'utilisateur peut accéder au canal 3) Si votre logique métier permet à la utilisateur pour accéder à ce canal, la méthode auth renvoie le « ok » réponse:

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

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

Je ne l'ai pas utilisé Pusher lui-même, mais son modèle semble refléter la structure des autres modèles par poussage. J'espère que cela t'aides!