I have set up a Docker environment running Jitsi with jwt login using jitsi-openid and last week everything was running fine. Today when testing though I just got errors when trying to enter any of the saved meetings in my list. After a while of digging I think I have found the problem, just trying to establish if it is a bug or what it is.
The problem is that the meetings in the list is saved in a cookie (features/recent-list) in the browser. In that cookie the entire url for the meeting including the jwt used for logging in is saved. That jwt however has an expiration date though, so when it’s used again a week later Jitsi doesn’t accept it any more.
I’m not sure how others do this, but I guess this would be a general problem, so I’m surprised I haven’t found anyone more complaining, which makes me wonder if I’m doing something wrong?
Anyway, from my point of view, the best fix for this would be if the jwt was stripped from the url before saving it in the cookie, it really makes no sense saving anything with an expiration date. Would this be possible?
This pretty much explains it, no? If you’re using a JWT with an expired date, it shouldn’t work. You need to either generate a new JWT each time you want to use it or you generate a JWT with no expiration date.
Yep, that’s exactly what I said. I don’t want to save the jwt. It’s not me saving it though, it’s Jitsi. The way it is now the list of saved sessions is completely useless since they are saved including an useless jwt.
Maybe I’m not fully understanding you, but it’s not about Jitsi saving the JWT (Jitsi actually doesn’t btw, the browser does), it’s about the time stamp on the JWT. If you want to use the same link with the same token over and over again, make sure you generate a token that’s not time-restricted.
No, I don’t want to use the same jwt. Having a jwt that’s not time restricted seems like a very unsecure and bad idea. I do however want the possibility to enter the same meeting and when I do so it should start the authentication again so that my identity provider can issue a new jwt with a new expiration date. Like I said in the first post, the meeting should be saved but not the jwt.
Yep, I guess that’s what I will have to do, better having nothing stored at all than things that don’t work anyway. Feels more than a workaround than a solution though, I really think that the jwt should never be saved in the first place.
Yep, maybe that’s right. Our goal is to create bookings directly from the (Google) calendar and then jump straight into them from there, so maybe the main page is completely superfluous. But with config.doNotStoreRoom=true and interfaceConfig.RECENT_LIST_ENABLED=false at least it’s working now if someone tries to use it
My next task is try to find out how to make only the person who made the booking become moderator, even if someone else gets first into the meeting. Seems tricky…