Hi Aaron, sorry if we didn't reply to your question last week. Are you still having this issue?
401 (Unauthorized) when saving changes
I currently have an issue when Bee editor will not save changes and is returning the following -
POST https://rsrc.getbee.io/api/nlparser?isPreview=false 401 (Unauthorized)
Saving works most of the time but it appears the issue can be triggered if Bee editor is not clicked away from before saving.
Please sign in to leave a comment.
Yes I am still having the issue, can I supply any further information that might help narrow down why this might be happening?
I still have this issue, are you able to provide help? Thank you
Hi Aaron, are you using beefree.io or the plugin version with your own integration?
We are currently using the Bee Pro plugin with our own integration.
Hi Aaron, that kind of issue is typically due to an expired authorization token. Very roughly, this is how the plugin authorization works:
- You start the editor with an authorization token.
- The token expires after a certain amount of time and is replaced by a new token by the authorization service.
- This refresh token loop exists automatically while the user is actively working in the editor.
- When the user saves the message (which is when you typically "close" the editor in your application), the token also expires.
Once the token expires, you need to perform a new token request to the authorization endpoint.
- You can do so by restarting completely the application
- You can also get the new token and pass it to a running instance of the editor (in the background)
The important thing is that you get a new token to restart the authorization cycle.
If you are designing a workflow where you need the editor to remain "active" even when the user is not working with it, one approach could be to make the container DIV hidden with CSS and display it again when needed. In this scenario, the editor heartbeat continues to exist in the browser, keeping the token refreshed and therefore avoiding authorization issues.
Yes we were already keeping the editor active by hiding its container when our document save area is displayed and so cannot understand why this issue sometimes happens?
Thank you for your help by the way.
We are also facing similar issue.
You mentioned earlier that we can also get the new token and pass it to a running instance of the editor (in the background). Can you be more specific and specify how to do that?
We still seem to be having issues with expired tokens, can you explain how to get a new token and pass it to a running instance of the editor in the background as previously mentioned?
Hi all, to properly work with third party cookies disabled, some changes were applied to the way the token is stored by the application. Because of this, currently it's not possible to pass a new token to the editor once is started.
The current work-flow maintains the last token active for 20 minutes since the last action done. After that, the application needs a new token, so you must request a new token to the authorisation end-point and load the editor again.
Our future developments includes the introduction of a procedure to pass a new token to an stand-by session of the editor, so please, add here your comments on how you plan to use such feature.
The more details we know about your needs, the better solution we will provide.