Closed TechnologyClassroom closed 2 months ago
cheers :)
BTW there is decent config here: https://github.com/deburau/galene-docker/tree/main/example-configuration-coturn/galene/data
Which branch are you running?
In Galene 0.8, using an empty username is disallowed unless you say
"allow-anonymous": true
In Galene 0.9 (current master), using an empty username is allowed, and there's currently no way to disallow it. If you think the feature is useful, I could add it back.
"" and null seem to do nothing.
The general rule in Galene is that setting "foo": null
is always equivalent to omitting the field "foo"
. This is required if we ever want to use RFC 6902 with Galene. I'll use the empty string for the purpose you suggest.
I'm running the master branch (commit e68ff8628749c1767f9744ce6a208da6a068a85a) with the LibreJS patch in production right now. I would prefer having the "allow-anonymous": true
config option as it could be worthwhile to potentially give more flavor to a faceless crowd. It is only a preference though and not critical.
Please be aware that the master branch is not always well-tested, but it's what's being used on galene.org, so it should be reasonably stable.
In Galene 0.9, the syntax of user definitions has changed. 0.9 will still parse the old syntax, but it will ignore allow-anonymous
. In order to achieve the same result, you need to use the new syntax:
"users": {"": {}}
Explanation: the above creates a user with empty username and disabled password, which forbids this user from logging in. (In the old syntax, lack of a password indicates a wildcard password; in the new syntax, lack of a password indicates that an account is disabled.)
Does that mean there will not be a method for wildcard passwords in 0.9? I did like that option.
For wildcard passwords, you now say:
"users": {"guest": {"password": {"type": "wildcard"}, "permissions": "present"}}
It's deliberately more verbose, so that you don't accidentally open up the server by omitting the password field.
Excellent! Thank you for the clarification!
Tested and it works. Thank you!
We've got this group example:
This allows ops and presenters to be given a password with the username of their choice. We found that some people did not follow directions and used the passwords as usernames so we created more user accounts with the passwords as the usernames and long passwords. This hack works. The message
The server said: not authorised
appears and the rest of the participants do not see the passwords.Using the same method, I cannot seem to do the same by giving an anonymous user a password to force users to pick a username.
I have tried these:
The NaN and undefined give an Internal server error when you launch. "" and null seem to do nothing.
This is not a critical issue for us after the recent /identify patches, but I did want to share my findings.
Feel free to use the example config for https://github.com/jech/galene/issues/198