ChannelAuthorizer supports only synchronous flow
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 15/100
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Java
- Sterne
- 315
- Forks
- 140
- Ø Merge
- 10 T. 14 Std.
- Gemergte PRs (30 T.)
- 5
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus pusher/pusher-websocket-java
-
java.lang.NoClassDefFoundError: com.pusher.client.Pusher$$ExternalSyntheticLambda0 on Android API 21-22 anywayEvtl. vergeben @Keith-wright hat das vor 9 Tagen übernommen. Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 22/100
pusher/pusher-websocket-java#366 ·
-
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 8/100
pusher/pusher-websocket-java#311 · 4 Kommentare ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 12/100
pusher/pusher-websocket-java#308 · 2 Kommentare ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 18/100
pusher/pusher-websocket-java#303 · 4 Kommentare ·
-
bug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
pusher/pusher-websocket-java#299 · 2 Kommentare · 2 Reaktionen ·
Alle Issues in pusher/pusher-websocket-java
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
quarkusio/quarkus-agent-mcp#302 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
build
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
MetricsHub/metricshub-community#1472 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
IdentityArrayObjectSet iterator remove may throw ArrayIndexOutOfBoundsExceptionEvtl. vergeben @jiteshkhatri11 hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
javapathfinder/jpf-core#660 · 1 Kommentar ·