I have been browsing these forums for quite some time trying to find a solution to my problem but haven’t found one that works so far.
The problem I’m having is that I have a client that has no option for authentication other then using a email address as a username. This however, has proven to be a slight problem for Openfire to handle. I have tried different solutions like creating a username with \40 instead of the @ and such but none has worked.
I’m not really sure what to do. I have been looking around for a way to see if the client has connected and attempted to auth but from what I can see in the logs they only show successfull connections.
I wonder, do you really need \40 in username? JID consists of username and domain. @ sign is added automatically. So if i have username john, and my server is email.com Then in Exodus client i put a login name as john@email.com. So i assume this should work for you too. Just name your server accordingly. The problem could be, that your client should be able to resolve that email.com address, so you can either edit hosts files on client machines to point email.com to your server’s IP address, or set up DNS records for your server. Though i’m not sure if this not interfere with real email.com domain DNS records. Does this email.com domain exists and is available on the Internet?
Okay, I suppose I was a little vague in my first post.
The problem is that the client is not running on regular computer. It’s a small app running on a GPS Tracker with NuCleus as it’s OS. However, I only have access to configure the Jabber client and it has it’s limitations. What I can specify is the server url, a port and then username and password. The client on the device accepts nothing other then an e-mail address or just something with a @ in it which is why it’s a requirement to me.
This also stops me from manipulating host files and such as they aren’t available however I am able to use a port-sniffer to verify that the GPS device is actually contacting my server on the correct port and sends the correct Jabber header to initialize communication. Se example below:
One issue with this is that <myservername> is not available on the internet. I have used Spark to connect to the same address as the device uses and I am able to log on though that so I am not sure it’s 100% related to simply the @ but according to the manufacturer, Openfire should work with it.
He told me to configure Openfire to ignore @ but I am unsure about how and I’ve looked through all of the configuration settings and can’t find anything about it anywhere.
I assume if I am able to do that I will have to setup useraccounts like <myname><myserver> but still use the formatting on my device as <myname>@<myserver>.
Any more enlightenment on this issue would be greatly appreciated!
his client is doing something it should not. It is using the JID for a username. The JID is composed of the username*@*servername. His client is then making his login credentials look like this: username@domain.com@domain.com which will not work. This is not an error with the server but an error with the client.
I agree, it’s the client that is faulty but it’s not something I can do anything about.
At this moment it would be easier if I could create a user that would be compatible eg. create an account called “myname@myserver” which in turn would be composed to a JID that would look like “myname@myserver@myserver” and would allow me to log in. I don’t care if it looks stupid or is messy but anything that will work at this point is more then welcomed.
Later on when more time is available I will take this up with the maker of the device and have them alter it for more compatibility. However, they did mention that any Jabber server would work and that it was possible to configure Openfire to disregard @ in a username which would solve my problem aswell.
Any tips about any of my options and how to set it up to work, no matter how silly would make my life less stressfull atm.
Thanks for your input though, it’s been of great value to help me understand what really is the problem behind this.
you should be able to create a user with an @ in the username. I assume you do not use LDAP. Just create the user in the admin site for openfire with the @ in the username. I just did this on my test box with no issues.