Post

5 followers Follow
0
Avatar

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.

Aaron

Please sign in to leave a comment.

10 comments

0
Avatar

Hi Aaron, sorry if we didn't reply to your question last week. Are you still having this issue?

Sergio M. 0 votes
0
Avatar

Hi there,

Yes I am still having the issue, can I supply any further information that might help narrow down why this might be happening?

Thank you

Aaron 0 votes
0
Avatar

Hi Aaron, are you using beefree.io or the plugin version with your own integration?

Guillermo Padilla 0 votes
0
Avatar

Hi Guille, 

We are currently using the Bee Pro plugin with our own integration.

Thanks

Aaron 0 votes
0
Avatar

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.

 

Massimo Arrigoni 0 votes
0
Avatar

Hi Massimo,

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.

Aaron 0 votes
2
Avatar

Hi Massimo,

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?

 

Makarand Thengdi 2 votes
0
Avatar

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? 

Aaron 0 votes
1
Avatar

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.

Guillermo Padilla 1 vote