How would I?
A) Go about restricting nicknames to First initial - lastname for nicknames?
B) Lock it down so users can not change them?
Thanks in advance,
Aaron
There are such options in the room creation form as: Make room members-only, Only login with registered nickname, Allow occupants to change nicknames. So you can control this in some way per room, but you cant control this per server and in a very convenient way. Usually users are allowed to select whatever nickname they want. You can register them in a room and then allow only members-only and only registered nicknames, but that will involve a lot of manual work every time.
That doesn’t seem to do what I need it to.
I need a more efficient way to manage Nicks and usernames. Also what is the difference between username and JID? Why does I replace spaces with /20? Will using LDAP solve this problem? I want to configure user accounts and not allow users to modify anything.
I have a feeling this software may not work for us since it is so buggy (i.e. not receiving message while in chat rooms, and nicks getting mixed up in other conference rooms, as well as unacceptable nicks being used.)
Any help will be appreciated.
Thanks,
First of all I would say that your assumption that openfire is buggy because you installed it with open acount registration and mangement is flawed. Secondly, you can and should receive normal messages while in group chats. If you are not I would look at the client or possibly some settings you configure in openfire (although I am not aware of any settings that would do this). Lastly LDAP is read only, therefore if you have your account information fully defined they wil not be able to make changes. Additionally spaces are not valid for web based usernames. Just like webpages and email addresses XMPP can only route JID info without spaces or other invalid web characters.
Todd,
Thanks for your response. It is not an assumption. I am using the latest version of Spark as well as Openfire.
I do not understand your first comment…an open account…flawed? Please explain.
I understand that LDAP is read only, this is not my question. I have users that when they type into a chat room, it shows up for some, but not for others. Another reason this software is buggy is, once a user’s is once voice is revoked in a room, there is no way to give it back without totally recreating the user account. Same goes for kicking a user, there is no way to allow the user back in once they have been kicked. They do not show up on the admin console as “Outcasts.” The way I found around this is to make the user an admin for the room by placing them in the group, then manually making them a member again. Not efficient at all.
If you wish to add a user permission to a room through the JID, there is no way to do it other than leaving the current tab to search for the JID in another function tab, then go back. With that said, there are way too many methods of identification for a user…JID, username, and nick. I have users that are using the JID in one group chat, and Nick in another. THERE ARE NO SETTINGS to mitigate this.
Furthermore, room permission(affiliation) groups have no ryme or reason. For instance, what is the difference between
-
Participant - where is the configuration?
-
Member
-
Admin
-
Owner
-
Moderators - where is the configuration other than real time(right click)…why can’t I revoke moderator once it is given?
Admin and Owner have only one minor difference which makes no sense. If I am admin or Owner and go to configure a room, I have no ability to add members, only admins and owners. In this case I am forced to go back to the admin console and add them manually using a clunky process(above).
Finally, what are registered nicknames? In IRC you can register a nick with the server by a cmd like msg nickserv register…there are no such commands here like this. Where are “Registered” nicknames held? How can I define them and lock users out from change or modification? If LDAP is indeed the answer, how are nicks formed if pulled from AD/LDAP database?
I have many more questions, but these are the most frustrating of them all. If anyone can provide solid answers I would be more than happy to revoke my comment about this software being buggy. It has excellent potential, I just can’t get it to work reliably. The only somewhat deep(tech savy) documentation I can find is some book that I am forced to buy. This is open software, why is there not a better documentation scheme other than basic descriptions of functionality. Am I missing the wiki for this?
Any help is greatly appreciated 
I will put it this way - this software wasnt designed for you. Yet it works fine the way it was designed for and it’s being used world wide by millions. Probably you will have to search for another solution or maybe design something custom.
I have only one thing to add to Todds post. Username is a part of JID. JID is username@domain.
wroot,
Excellent response to a long question. You gave no content, just a condescending antidotal comment. If it was not designed for business conference management, what was it designed for? Quoted from the about page on ignites website “interested in applying innovative, open-standards-based Real Time Collaboration to their businesses.”
I have all those issues listed which are obvious problems, and you just come up with that response? No wonder you have so many posts under your name. I will withdraw my comments when you answer the questions posted with valid responses. Not just some sly way to get another post added to your username and sound smart.
I find it hard to believe that millions use software that:
A) has poor support documentation B) has a support chat that is not even functional C) is not “designed” for business use D) only has one book written on its administration E) Extreamly poor user mangament.
If I am wrong please inform me where to get more information.
I wasnt replying to your long question and i saw it only after i have posted my last message. Speaking about the millions, i was referring to Jabber/XMPP in general, as Openfire is (or tries to be) a XMPP compliant software. Personally i dont think this software (jabber) was designed for a business. It’s just a messaging platform with some extension capabilities. Of course business software can be built on top of it. JiveSoftware (owner of this site) was thinking they can make business software and make money, and they were selling it (Enterprise version). So they have written this “beautiful” About page. Me and Todd and many others here are just users, we dont manage this site. You can contact JiveSoftware if you dont agree with something on this site.
Speaking about Openfire: A) yes, it has only some basic documentation. The fact that software is open doesnt mean that detailed documentation will pop up automagically. Someone has to write it and apparently nobody wants or can. B) were you speaking about http://www.igniterealtime.org/support/group_chat.jsp ? It is working now. Though sometimes it doesnt, but again, one should contact JiveSoftware about that. E) you can call it extremely poor, i call it basic. It has some bugs ans issues. Some of them are being fixed, some will be fixed, maybe, maybe not. That’s the other side of open software. Sometimes there are not so many people willing to contribute. JiveSoftware is not very interested in these projects anymore.
Now. About your long question. I may answer some of this later, if i’ll find some spare time to investigate, because i dont use group chat much. Though, i assume you will probably be gone before that.
by allowing manually created account the users of those account have full control over the functionallity of the acounts. This means they can change any of the data pertaining to their vCard (First, last, nick names, etc). With LDAP all these vCard settings are predefined and cannot be altered by the end user. You determine what fields are used for the Display Name for the roster in spark, what field is used for the Nickname, etc. They cannot be changed.
Many if not all the other issues you are describing are client limitations (ecept maybe revocation issues). Spark is not the end all be all client. I am not sure if any client will do all you are asking for.
I have users that when they type into a chat room, it shows up for some, but not for others.
I haven’t seen this and can’t reproduce. We need more information about this. What clients do they use? I assume everyone are using Spark? What version then? Can you try the latest SVN version of Spark on those problematic clients?
Another reason this software is buggy is, once a user’s is once voice is revoked in a room, there is no way to give it back without totally recreating the user account.
I have just successfully revoked and granted back a voice permission to a user while being an admin of the room. I’m using Spark. It’s the latest SVN version and i cant test it with 2.5.8 right now, but i don’t remember such issue reported/filed or fixed in the past.
Same goes for kicking a user, there is no way to allow the user back in once they have been kicked. They do not show up on the admin console as “Outcasts.” The way I found around this is to make the user an admin for the room by placing them in the group, then manually making them a member again. Not efficient at all.
Well, they shouldn’t show up in the Outcasts group, as they havent been banned. They should be able to connect to a room again. I have tested this with Spark, Exodus, JBother. Everything works fine.
If you wish to add a user permission to a room through the JID, there is no way to do it other than leaving the current tab to search for the JID in another function tab, then go back. With that said, there are way too many methods of identification for a user…JID, username, and nick. I have users that are using the JID in one group chat, and Nick in another. THERE ARE NO SETTINGS to mitigate this.
This is not a “flaw” of this particular software (Openfire/Spark). This is XMPP standard and Openfire is following it. I can’t answer why such approach has been chosen, but probably there were some reasons. As i said in my first reply, there are some options to control what nicknames users are using, but this is not very convenient. There are no more options for that, because this is not required by standards. As i said, this software (and XMPP/jabber in whole) is not designed for your specific needs, so maybe you better search for a more suitable solution.
Furthermore, room permission(affiliation) groups have no ryme or reason. For instance, what is the difference between
- Participant - where is the configuration?
- Member
- Admin
- Owner
- Moderators - where is the configuration other than real time(right click)…why can’t I revoke moderator once it is given?
Participant doesnt have any configuration. It is a plain group chat visitor with a voice permission. Member is a participant and also belongs to Members group. So, if “Make room Members-only” is enabled, then basic participants won’t be able to join that room. Only Members will be able to join. Admin have options to grant or revoke voice, moderatorship, kick and ban users. Owner has all the admin’s rights, but also can configure room’s settings, voice/moderators/admins/owners/etc. lists and also destroy a room. Spark doesnt have every owner’s and admin’s setting, but i wouldnt call it “buggy”, it just doesnt have all features. You can use other jabber clients with Openfire (e.g. Exodus has more admin’s/owner’s options). Someday Spark may have all these options. Moderator has no configuration because it is only for a one session. If you quit a chat, you loose moderator’s status. I’m able to revoke moderator’s status with the latest SVN version of Spark.
Admin and Owner have only one minor difference which makes no sense. If I am admin or Owner and go to configure a room, I have no ability to add members, only admins and owners.
There is a sence. Admins cant destroy a room, edit its settings and add another admins or owners. Admin is like a moderator, but this permission is not taken away after one quits the chat and also should give permission to edit voice/members/moderators/ban lists. Same with the owners. Spark is lacking this additional options.
Finally, what are registered nicknames? In IRC you can register a nick with the server by a cmd like msg nickserv register…there are no such commands here like this. Where are “Registered” nicknames held? How can I define them and lock users out from change or modification? If LDAP is indeed the answer, how are nicks formed if pulled from AD/LDAP database?
Registered nicknames are the nicknames that users decided to register with a particular room. So, no other user can use that nickname in that room and also they cant change their nicknames if “Only login with registered nickname” is enabled in that room. So, to restrict nicknames server administrator would have to login with every username, join a room and register it with a legal nickname. As i said before, this is not convenient. Registered nicknames are stored in database and there is no interface to manage them, because there is no such requirement. Registering was intended only for users, not for admins to manage. Of course, someone can create such interface and contribute it to Openfire project. Todd has already told about the LDAP approach on this.
Sorry to beat a dead horse, but reading through all of this I did not actually see any solution to locking down nicknames.
Is there an actual solution for this. It is kind of scarry that any user can give themselves any name and it appears that way in a conference. (Boss saying your fired, spoofed employee name tell off boss, etc…)
No, there is no solution to this so far, and it doesn’t look there will be one. Almost no developers here.
I have made minor change to code.
This forces nickname to be same as username.
Change this file:
src/java/org/jivesoftware/openfire/muc/spi/LocalMUCRoom.java
// String reservedNickname = members.get(user.getAddress().toBareJID());
** String reservedNickname = user.getAddress().getNode();**
i.e. comment the striked out line and add the bold line
Currently its line number 568 in
src/java/org/jivesoftware/openfire/muc/spi/LocalMUCRoom.java
Hope it helps someone.