Restrict Login not working?

Openfire Openfire Support
1

I’'m running Jive Messenger 2.2.0 Beta 1 and am having problems with the Restrict Login setting on the “Registration & Login” page. I want to restrict logins to our local subnet. From the description I need to enter an IP address or IP address range. I have tried “192.168.0.*” as well as “192.168.0.1,192.168.0.254”, but as soon as I put a non-blank restriction in users can no longer register automatically. If I put a specific IP address in it works OK.

I’‘d rather not enter all 250+ IP addresses if I don’'t have to. Am I using the wrong format, or is this feature not fully implemented?

Thanks,

Gary

2

Hey Gary,

That functionality is fully implemented so you may have hit a bug. Check out the error.log file to figure out the actual IP address of the socket connection that was closed by the server. You should see something like this:

2005.07.26 16:33:37 [org.jivesoftware.messenger.net.SocketReader.run(SocketReader.java:145)

] Connection closed before session established

Socket[addr=/127.0.0.1,port=2121,localport=5222]

More precisely, check out the “addr=/…” section. That part indicates the real IP address that the remote client was using to connect to the server. So in my example you may use “127.0.0.*” so that only the PCs under that range are able to connect to the server.

Also, make sure that Inband Account Registration is enabled if you want users to be able to register with the server using an XMPP client.

Let me know if you see any error in the logs.

Regards,

– Gato

3

I have a bunch of errors in the log file that look like this:

2005.07.25 13:38:34 [org.jivesoftware.messenger.net.SocketReader.run(SocketReader.java:145)

] Connection closed before session established

Socket[addr=/192.168.0.119,port=15905,localport=5222]

This is the IP address of the machine that is trying to connect

I have turned on Inband Account Registration. I am currently running the server with the Restrict Login blank and people can register themselves.

This is probably a stupid question, but do I need to restart the server when I change the Restrict Login setting? I haven’‘t been doing this because I noticed that if I changed it from “192.168.0.*” to either blank or a specific IP address it worked fine and if I changed it back it didn’'t.

Thanks,

Gary

4

Hey Gary,

I was not able to reproduce the problem. There is no need to restart the server after configuring the restrict list. The server will notify you if there is a need to restart it. Currently, you will need to restart it if you modify the hostname.

This is what I tested in my local server:

  1. Started up the server.

  2. Set the restrict list to: 127.0.0.*

  3. Logged in with a user

  4. Cleaned up the restrict list

  5. Logged in with a user

  6. Set the restrict list to: 127.0.0.*

  7. Logged in with a user

  8. Cleaned up the restrict list

  9. Logged in with a user

  10. Set the restrict list to: 127.0.0.*

  11. Got tired and stopped

Let me know how may I reproduce the problem.

Regards,

– Gato

5

After a little testing I have found that I can get restrict login to work if I:

  1. Set the Restrict Login box to “127.0.0.*”.

  2. On the client, I set the server to “127.0.0.1”.

  3. The client is running on the server (obviously).

If I use the actual hostname instead of the loopback address for the server in #2 it doesn’'t work. This was sort of encouraging, so I switched the Restrict Login box back to “192.168.0.*” and set the server name on the client (gaim) to the IP address of the server “192.168.0.20”. Sadly, this did not work.

I don’'t know if this is helpful, but here is what the debug log says when I tried this:

2005.07.27 08:43:13 Connect Socket[addr=/192.168.0.20,port=21495,localport=5222]

2005.07.27 08:43:13 Closed connection to client attempting to connect from: 192.168.0.20

So, I can get Restrict Login to work if I use the loopback address in the Restrict Login box and use the loopback address as the server name on the client, but everything else I have tried has failed.

Any ideas?

Gary

6

Hey Gary,

The name of the server is not involved in the restriction logic. I finally narrowed down the problem and fixed it. You can use the next nightly build and try again. The jira issue for this problem was JM-352.

Thanks for the bug report.

– Gato