Hi all,
I have installed Openfire with “Openfire meeting” plugin on my server.
My purpose is to create a fixed set of rooms with anonymous access.
I don’t want users to register, nor to be able to create new rooms.
I know that room creation can be restricted to just some users in Openfire interface, but I’d want to block anyone from creating rooms by using a link like this: https://my.server:7443/ofmeet/anything
At the same time I’d want to keep free access to the rooms I created as admin through the Openfire interface.
I would suggest to solve this by putting a reverse proxy in front of Openfire, and only allow certain URLS to be forwarded to Openfire. That way, you can probably also remove that ugly port number.
I might be misunderstanding your reply Guus, or I might be misunderstanding the original post; but I think we have the same issue as Hippocrate,s and implementing the reverse proxy doesn’t seem to have any effect. We’re using:
Openfire: 4.5.1
Openfire Meetings: 0.9.5
We’ve enabled anonymous login and have configured Room Creation Permissions like this:
We’re expecting that anonymous users can only join an existing Room. Sadly, anonymous users are able to create and join any Room they like.
It feels like we’re missing something obvious. But it’s not obvious enough
Thank you for the quick (immediate??) response.
And thank you for the solution to a problem which has been bothering me for a very long time. Anonymous users can now join Persistent Rooms and are denied access to any other room.
Your solution is perfect … except for 1 little thing that I’m prepared to experiment with, but if you can provide the solution as quickly as your previous solution, my life will be much richer
With the solution you’ve provided, as soon as an anonymous user joins a meeting in a Persistent Room, he/she is added to the list of Owners of the room, and remains as an Owner even after exitting the room. I’m not sure if this is a real problem, but I find it to be terribly irritating. Almost to the point of losing sleep.
Is there an equally simple solution to this? Or should I continue experimenting?
The logic for this is buried deep inside Jitsi offocus code. I am too busy to have a look at the moment, but I will add it to my todo list to check out sometime soon. If we are lucky, there will be a parameter/setting to configure it.
It might not even be as bad as it sounds because anonymous usernames are one-off and not re-use-able. A simple solution might be to just clean the list when the focus user leaves the conference.
Sorry to occupy this thread but I think I have very similar problems / requirements. Please tell me if I should start a new topic for this…
I’m very impressed with the new features added to OpenFire/ofmeet/pade! I almost can’t follow your pace.
I’m currently testing with the v0.9.9 plugins and I like the new functionality a lot.
But I’m missing a feature I have working in a plain and simple Jitsi Meet installation (with authentication configured in prosody): Video Chat “guests”
In detail I want to achieve the following:
Only users registered by an admin should be able to authenticate against the OpenFire server
Only authenticated users should be able to use services of the OpenFire server and to start a video conference or peer-to-peer video chat
A user who already has authenticated at the login screen of the pade web plugin should not have to authenticate again when starting a video call inside pade.
An authenticated user should be able to start a video conference inside pade and invite a guest user who is not registered. The guest user should get the address of the conference by some means (e-Mail, phone call, …) and then be able to join the conference without authentication
If the authenticated user who started the video conference chose to add a password to the conference, the guest user should have to enter the password before joining the conference.
Currently it seems I am not able to configure the systems in such a way.
I followed the suggestions given in this thread, but:
if I enable anonymous login (Server settings -> registration & login) unauthenticated users can create and use new conferences just by entering an URL like https://server.domain.tld:7443/ofmeet/foobar - this is not what I want.
As suggested I removed the focus user from the list of group chat administrators in Group chat -> Group Chat Settings ->conference -> Administrators but still users can start a new video conference without authentication. I also tested with the Room Creation Permissions set to “All registered users can create a chat room”. If I uncheck the “All registered users can create a chat room” option but instead give a list of allowed users and groups, video chat breaks completely, not even registered users can start a video call in this situation but instead always get a “Unfortunately, something went wrong” message.
If I disable anonymous login, unregistered guest users can not create video conferences, but they also can not enter existing video conferences as the system then always requires authentication with username and password.
Did I miss or mis-configure some important configuration or is it currently not possible to configure OpenFire to work as described above?
Yes. Pade uses the browser Credentials Management API. In other words, it will use the password stored in the web browser. Provided uses let the browser store their password, it should work.
Yes, but as you would have disabled anonymous users, you have to create a generic user called guest or visitor or whatever with a protected well known password. Treat the password as a security token and include it in the email invitation to the invited user. You now have the bonus to control the access permissions of this generic user(s). You could even create multiple generic users based on purpose, role or any type of grouping.
Yes, by using standard XMPP conference room passwords. It can be set in Openfire or directly from the Jitsi-Meet web client.
This is your best option to support public, protected and private users. Enable the password caching option in Openfire Meetings to make sure visitors only need to enter the security password only once. Jitsi-Meet will prompt for their actual Display Name
Earlier in this thread, you provided an elegant solution for Openfire: 4.5.1 & Openfire Meetings: 0.9.5
to enable anonymous users to join Persistent Room meetings, while preventing them from creating new rooms. To summarise your solution:
allow anonymous users
restrict Room creation to selected users
and the elegant part
remove the Focus user as Administrator for the service
add the Focus user as Administrator for each room
This worked flawlessly … until we moved to Pade Meetings 0.9.9(which we really, really like)
Now, if we remove the Focus user as Administrator for the service, nobody can join any meeting, anywhere (yes we did add the Focus user for each room) AND whenever the Openfire service is restarted, the Focus user is restored as Administrator for the service.
We’ve worked around this by adding guest accounts as you suggested to andreas2020, but this seems a little … ‘less elegant’ somehow.
Do you have an equally elegant solution for Pade Meetings 0.9.9?
Sorry about that, but Jitsi may have changed the way jifco worked between version 0.9.5 and 0.9.9. I will try and dive into their code to trace their changes as soon as I get a free moment. If they provide a configuration setting then we are in luck.
That is offocus and I should be able to make this a configurable setting in Openfire.
Focus user conference admin status is now configurable
As far as I can tell for my testing 0.9.9 is behaving like 0.9.5. You can’t use a room for meeting unless you add focus user as a room owner. This means nobody can create temporary meeting rooms. All meeting rooms must be persistent chat rooms with focus user explicitly added as a room owner.
