I see, this makes sense then. If a user has an access_token generated, they MUST use the access_token. So you’re getting rejected because you’re attempting to login as the user without the access token. Can you try using a user without an access token and see if you get similar results?
I can only reproduce this behavior when I pass in a user that requires an access_token. When I enter a user that does not require an access token or session token, this works as expected.
But what I tried is to delete the user, and create it again, and now it works… I guess I’m going to have to do that for each user, but I’m really not sure why…
Users do not have any kind of expiry. It would be best to get an example user I can take a look at that is having this issue before you delete the user to fix it. Once the user is deleted, I won’t be able to investigate.
I’ve got some new info. In our backend we have implemented the creation of a sendbird user when a user register.
And since we tried to implement the creation of a token as well, thats what was causing the issue. The session token was created, but it wasn’t added to the Sendbird user, and I think that’s the reason we couldn’t see it in the Sendbird Users Dashboard.
Removing that logic, fixed the user creation, and I will probably have to remove all the accounts and add them again.
Other than that I think that some kind of error would be good to indicate what’s wrong, because currently the only thing we see is a loading spinner.
Ahh, I think it’s important to make a distinction between sessionTokens and accessTokens. sessionTokens are JWTs and are not saved anywhere on Sendbird’s servers and thus they wouldn’t be displayed anywhere. accessTokens however are non-expiring tokens that are stored in our database and thus they can be displayed on the Dashboard.
It’s not that it was clashing with a sessionHandler. It’s just that whenever a user has an accessToken or sessionToken generated, they MUST log in with that token. They can no longer login without one.
So because your backend was generating sessionTokens, they needed to be logging in with a sessionToken.