I ive 2 servers communicating with each other via server 2 server (wildfire 3.1.1 and openfire 3.3.2 ).
Ive the client Spark and i see in the roasters users with loginname@domain ( when they are from the remote server) messed up with the normal usernames…i think its a bit ugly to see these 2 different formats when i don´t inteand the users to see each other login names ( ex: using another client changed to show only the usernames)
The problem is that the only packet changed beetwen servers to show presense of users is a presence packet with loginname@domain.
Is there any way i can configure the server/client so that i see only the usernames?
The users manually added to the a users roster if they are on another server? If so you need to set the nickname at the time of adding them or it defaults to the account name. You can rename them via a right click on the display name.
The objective is forcing users to know each other only by the “Name” pre-configured in the servers…they will not be able to change other users name (they will see what they get from server).
The usernames(login names) are forbidden to see and so is the domain…
The domain its easy, it can be filtered changing client app. The problem is the “Name”… if the remote server dont send me the “Name” ( it only sends username@domain ) i will not be able show the names in the client app…shouldnt the server exchange their names?
I have configured like this:
In server1 i have these users in roster:
aaa@server2.net (remote user - defined in the remote server only - server2 )
bbb (local username - its defined in the local server - server1)
In server2 i have these users in roster:
bbb@server1.net (remote user - defined in the remote server only - server1 )
aaa ( local username - its defined in the local server - server2 )
Is that a another way to configure them so they exchange names ?
The usernames(login names) are forbidden to see and so is the domain…
Every XMPP entity is identifed at least by a loginname@server.domain i.e. a jabber id or JID. I couldn’t think of how an XMPP system could be tuned to securely obscure any part of the JID. You’ll just have to accept that as is, and from there start to work your way up.
“The usernames(login names) are forbidden to see and so is the domain…”
What i was trying to say is that my client app would be modified so the users never see the jids ( jids are not necessary for people to indentify each other when they try to speak beetwen them…the name is sufficient ). Users will only be created/changed by admin in the openfire…
It works on two ways:
people gets less confused ( they only see a name…not jid or/and name)
security : if someone knows the jid of the other …other user just has to guess the password. How about hide jid from each other?..more secure i think (to the user and to the server)
presence with only the JID dont seem to allow the client app (connected for instance in server1) to receive the names of the users defined in the remote server (server2)
I would like to receive the name of the user in a packet (associated with jid of course) so that the app would know the names from users on remote servers.
Or else its a messy thing …some users are seen with name other are seen with jid …doesnt make sense as i dont want the users be able to give as they like names to other users
OIC… Correct me if I’m wrong… So you’re setting up a messaging system where:
You’ll use it within your LAN only
Only your custom-built client can connect to it
Your users don’t have any idea that the system is an XMPP
As a quick thought, I think this can be done if you write a plugin for Openfire that implements PacketInterceptor. For all intercepted packets you can inject something like a custom tag e.g. machu, which is understood by your client.
To cater for item 2 above, I’d suggest that you identify your client in , so that you plugin can reject all other clients. Just in case, so as to avoid some smart users who happens to know that your messaging system is actually an XMPP system.
as Aznidin said you really want to use a server plugin to modify the packets which are sent to the client. Or if you use a custom client you could also change their the JID to a name, but doing this on server side is much more easy to handle, especially if new users are added.
I think that I know what machu wants because I have the same problem…
With 2 users in the same server there is available to jabber clients the user name instead of login name. ie. mailto:somename@bla.com and ‘Some Name’.
The last is displayed on the Roster. With a connection between 2 servers why is not the user name available ? It should be…the servers are the same, as is protocol…so…It should be available…no ?
This could be a server develop problem or feature request, it makes all sense to have login name sent to jabber client app.
OIC… Correct me if I’m wrong… So you’re setting up a messaging system where:
You’ll use it within your LAN only
Only your custom-built client can connect to it
Your users don’t have any idea that the system is an XMPP
thats it
About your suggestion, it think it could be one solution…
I thought the protocol between the servers would permit the client app receive the “Name” of the users, either users are from same server or from the remote server. Like jcorreia says, why do i receive the names from users in my domain (server that im connected directly) and dont receive the names from users in other domains (remote server)? Isnt this a little fault? That feature would permit more tranparency to the client app! dont you agree?
It seams there are more people in the communitty with similar problem as me and jcorreia…
it2000 ,
but JIDs are always username@domain…how could i get the “Name” even if a custum client app?
I thought the protocol between the servers would permit the client app receive the “Name” of the users, either users are from same server or from the remote server.
Actually, the S2S protocol is not any fancier than the C2S. You can think of an S2S protocol as an extension to C2S. That is, it can do whatever C2S can because most of the time S2S just wraps C2S packets in packets. When a sending server send a packet to the destination server, the destination will remove the wrapping and process the stanza it contains as usual, be it , or .
Or else its a messy thing …some users are seen with name other are seen with jid …doesnt make sense as i dont want the users be able to give as they like names to other users
If you don’t like the default roster functionality and want to control the Name that gets displayed on your custom client, then like LG and I suggested in the previous messages, you’ll need to write a server plugin.
Thanks aznidin, im trying to sort out ( curious ) how the server 2 server protocol really works… in my tests i found another problem, this one is really uggly:
OFFLINE messages do not work if:
server1
server2
user_a (at server1)
user_ b (at server2)
result
ON
ON
sends msg to b
OFFLINE
SAVES OFFLINE MSGs IN SERVER2! (in remote server?..hum…)
ON
DOWN
sends msg to b
OFFLINE
DOES NOT SAVE OFFLINE MSGs! (because he tries to send them to de server2)
users from remote server dont receive OFFLINE msgs if the remote server is DOWN …but the user that sends them is able to send them!!!
Messages are lost if one of the servers goes down!..It depends if i am writing to a user offline on a remote server or local server
Am i missing something? If its not a bug …well…i am expecting receive offline msgs… i configured servers to do so!
This s2s protocol seams very very limited…it exchanges presences…nothing more…the rest is done by the local server…look at the example of the rosters…i never receive the names from users from remote server because the local server takes care of it , sending this to me:
This is a response from local server to a query for roster…he assumes NAME = JID as you can see …he does not comunicate with the remote server in this situation!
The basic rule applicable for a sent message is that, if the destination is not known or if an error occurs at any point while delivering the message, the default server behaviors are:
Drop the message
Don’t report the error (even success) to the sender
This rule applies accross the client-server-server-client chain. An obvious advantage of such rule is that, it will reduce the chance of SPIM and for security purpose. Imagine if the sender is someone bad, trying to guess a user’s account and start to send unsolicited message.
If you think of the said rule and try to apply it in offline messages context, the scenarios you mentioned made perfect sense.
The roster and offline storage for a user and any information related to the user are managed only in the server where the user has an account. In an environment where different server domains are connected to each other, that seems to be the best way to manage and control users. It would be a havoc if each server is to manage the entire users. You will quickly run into security problems and the problem of synchronizing information between servers.
In an analogy, a country will manage its own citizens. First, it would be rediculous if a country manages the whole world. Second, Imagine that you and I are from different countries. We are basically allowed to communicate with each other, but will your govt release all your information to me? I don’t think so. However that could work if both our govts run the country plugins .