Troubleshooting information for the Real-Time Collaboration (RTC) plugin
Useful information for troubleshooting issues with the RTC plugin.Contribute to this page
This documentation is in progress. Please contact us with any suggestions you think should be here.
A secure context is required for Real-Time Collaboration. Browsers restrict some features to secure contexts, including features required for Real-Time Collaboration. Ensure that your web server is set up for HTTPS and your development server is accessable using HTTPS or
What happens if two clients attempt to establish a session at the same time? What impact does that have on encryption key generation?
As noted in the Document ID configuration option, if a document ID is not known to the server, new initial data will be uploaded. If two users manage to do this at the same time, one will be forced to wait for the other to establish the session. This has implications for configurations using a dynamic
If the situation occurs, the connection process for the RTC plugin will be as follows:
- Both plugins request a session for the document ID, and the server does not have an existing session.
- Both plugins use the encryption provider to produce an encryption key with no key hint to encrypt the initial content.
- Both plugins send a “create session” request to the server.
- One connection “wins”, and the other is “rejected”.
- The rejected connection waits for further instructions.
- Once the winner completes establishing the session, the server broadcasts “new session available” to all clients connected for the same document ID. This message will include the key hint from the winning encryption key.
- The rejected connection uses this key hint to generate the same encryption key as the winning connection and collaboration begins.
As a result of this process:
- If encryption keys are dynamic, old keys cannot be discarded immediately when a new key is generated.
- For any given key hint, the same encryption key must be returned every time.
Care must be taken to avoid losing encryption keys to this race condition.
If the below error descriptions do not solve the problem, try pasting the token into the https://jwt.io/ Debugger for detailed token-format debugging.
RTC requires an asymmetric signing algorithm for JWT identity tokens. Asymmetric signatures use separate private and public keys; the public key stored on the Tiny Cloud server can only be used to verify signatures, not create new ones. The private key, used to create new signatures, remains private.
For a list of supported algorithms, see: RTC JWT Authentication - Supported algorithms.
Time-based errors include:
- JWT was issued in the future
- JWT has expired
- JWT is not yet valid
If the system clock on the device that signs JWTs is incorrect, the Tiny Cloud server may return one of these errors. RTC only requires the
exp claim as an expiration timestamp, but other optional timestamp claims can be used to protect a token from misuse. If the client or server clocks are significantly different, time-based errors may occur.
To resolve this issue ensure all computer clocks are synchronised using NTP or a similar service.
A “JWK set” is a structure that contains public keys for validating JWT signatures. At least one public key in the set must match the private key used to sign the provided identity token for RTC. This error means a public key could not be found in the Tiny Cloud account of the Tiny API key used to load the RTC plugin. For information on creating public/private key pairs, see: JWT Authentication.
A number of part-related errors can be raised if the JWT fails to decode:
- Not enough parts
- A part was not correctly base64 encoded
- A part was not valid JSON
- The header part does not specify an algorithm
- The payload part does not contain all required claims
Thanks for the feedback!
Can't find what you're looking for? Let us know.