Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

ChannelAuthorizer supports only synchronous flow

Abierto
  • ¿Algo no está bien?
#340 3 comentarios 7 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
java, kotlin
Área
api

Línea de trabajo

The work centers on the ChannelAuthorizer interface and its authorize(channelName, socketId) method, which returns a String synchronously. Start by reading how the authorizer's result is consumed when a private or presence channel subscribes. The issue proposes a callback-based variant plus a compatibility path for existing implementers, but the API shape is not settled. Done would require an agreed design, a backward-compatible implementation, and tests for both sync and async authorizers.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What is the issue?

Currently ChannelAuthorizer expects a synchronous authorize implementation that returns a string.

It would be nice to rewrite it in a more asynchronous way, so that ChannelAuthorizer interface wouldn't force the implementation to block the thread if authorize requires async job.

It limits Kotlin usage e.g. in your React Native SDK, that needs async job by design (of React Native bridge):
Native Java/Kotlin module sends an event to Javascript and later Javascript calls Native module with auth object.

Related issue in your React Native SDK: https://github.com/pusher/pusher-websocket-react-native/issues/37

Is it a crash report? Submit stack traces or anything that you think would help

Nope, but please check the linked issues for more context and possible freezes/errors.

Any improvements you suggest

The React Native SDK (Android/Kotlin code) uses mutex to block the thread and wait until JavaScript returns proper auth object through RN bridge.
It's not really a common flow in RN world (to block the thread in RN module), because it can lead to various issues/freezes/crashes/leaks.
Instead, it is preferred to implement logic in an asynchronous way (listeners/storing callbacks) since RN bridge is also asynchronous.

There was a similar but more serious issue in iOS part of your React Native SDK:
https://github.com/pusher/pusher-websocket-react-native/issues/34
But it can be fixed by simply storing callbacks instead of blocking the thread:
https://github.com/pusher/pusher-websocket-react-native/pull/36
However, it is not possible to implement it like this in Android (Kotlin) part, because of the ChannelAuthorizer interface.

So my suggestion would be to rewrite ChannelAuthorizer in a way that supports async/delayed response.
For example (there might be a better way, but this should do the job):

// old
String authorize(String channelName, String socketId)
// new
void authorize(String channelName, String socketId, Callable<String> authResultCallback)

I know it would be a breaking change, but it should be possible to add backwards compatible util (that simply calls authResultCallback instead of return) or support both ways.

CC @pusher/mobile

Lenguaje dominante
Java
Estrellas
315
Forks
140
Merge medio
11 d 5 h
PR fusionados (30 d)
4

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pusher/pusher-websocket-java

Todos los issues de pusher/pusher-websocket-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.