NPE on admin console > muc affiliations site

Is this allready been fixed? I did not find sth in the changelogs …
I get a NPE when i try to visit the users affiliations site for muc room on the admin console…
OF 4.5

java.lang.NullPointerException
	at java.net.URLEncoder.encode(URLEncoder.java:204)
	at java.net.URLEncoder.encode(URLEncoder.java:170)
	at org.jivesoftware.openfire.admin.muc_002droom_002daffiliations_jsp._jspService(muc_002droom_002daffiliations_jsp.java:563)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
	at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129)
	at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:73)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:49)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:226)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
	at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:234)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1700)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1667)
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.eclipse.jetty.server.Server.handle(Server.java:505)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427)
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321)
	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804)
	at java.lang.Thread.run(Thread.java:748)

I’m not reproducing it in Openfire 4.6.1. Care to try and upgrade? :slight_smile:

It is only in onw room but i cant see the users without looking into the database… but i am nut sure what causes this exception…

That encode method that’s causing the problem is being invoked in a lot of places, but seems to be limited to only two bits of data. The URL that you open, does that have a roomJID query parameter? Is that particular MUC using a user-group, and if so, do you somehow have a user-group without a name?

OK the link would be:
http://server/muc-room-affiliations.jsp?roomJID=group1@conference.mydomain.local&create=false
the muc does not use a user group… its created by myself…
I opened muc-rom-occupants.jsp and noticed that there is a user with a nickname which has a whitespace… like “Andy G.” … all other users dont have a whitespace… could this be a problem?
and i could not find another string or sth like that which causes this…
but if i kicked the user… the problem is still there…

Exactly what version of Openfire are you using?

it was the master somewhere between 4.4 and 4.6… but the local file was last touched @ 19th december 2019

UPDATE: we are going to update to latest release in 2 weeks but before we have to set up the database cluster… then we will see if it still happens…

EDIT:
i had a look into ofMucMember and found two interesting lines for this room:

  1. there is one user with an “ü” (only one) so maybe this character is not escaped…?
  2. this is more interesting… i dont know how this could happen but in col. “jid” is a line with a faulty jid. this entry only has a node part without the corresponding @domain part… i will change theese lines in the database and try whether this fixes the problem…

ok i edited the database entries … but without restarting openfire service, the problem was still there… after restart it was fixed… so either it was the character “ü” or the missing domainpart in the jid…

EDIT2: i have found some other invalid jids in the database and edited them too…

so we should take care on faulty jids when adding them to the database or throw an exception to send an error back…and if its a localuser (user not from a federated server) we also should check if it exists… because the ü was wrong too because the username was only valid with ue in this case above…