Icon shouldn''t show up for transport where user isn''t allowed access

Openfire Plugins Kraken - IM Gateway
1

I don’'t know if this should be posted here or in the Spark forum…

I’'d like to be able to restrict access to the gateway on a per user basis. While that is possible, it seems that all users still see the icon for the transport in Spark once I enable it. This is not good since it will create confusion as well as alert other users that the gateway “exists.”

I believe the correct behavior would be for the icon to only show up for users that have been manually registered or that are allowed to register themselves.

2

Howdy! This is a known issue, and it’‘s more or less a “collaboration between Spark and the plugin” type of thing. I’'ll explain why in a moment. First off, just wanted to point you at the issue in the issue tracker: GATE-216

Anyway, the problem here is that the existence of the transports is pulled via disco. When a transport starts up, Openfire queries it for it’‘s items and info list and caches those results. (this is common across servers) As a result, there’‘s no knowledge of the user at the point of finding out X transport exists, so there’‘s no way to say "you don’'t have access". A solution might be to have Spark do an additional query of some sort to ask if the user does have access.

3

Thanks! I assumed as much although I wouldn’'t have known the technical terms to use. I assume that Derek is aware of this?

4

Uhm. ;D Maybe? I think I mentioned it to him. I don’'t recall if we talked it out much though.

5

jadestorm wrote:

A solution might be to have Spark do an additional query of some sort to ask if the user does have access.

Please don’‘t do this! You’'d force every client developer to implement your nonstandard extension. The standard mandates that the disco#items-response should be changed depending on the requesting client. This means that this is a missing feature in Openfire and should be added there.

6

Spark is already doing non-standard things. Point me to where it says the standard says that the items response should be changed based on the requesting client. Also point me to another server that does -not- implement it like this. When you connect the transport the server asks the transport for disco items. Immediately. There is nothing in the response to indicate “these users are allowed to see this transport” so there’‘s nothing for the server to work with to know what to tell the end client. It would be horribly inefficient for the server to re-request an items list every time someone did a service discovery. Besides that I’‘m not forcing any clients to do anything. If I did implement this, it would be an indicator that "you don’‘t have access to this" via standard disco, in some way shape or form, via a disco#info inquiry. Clients that work like Psi won’‘t care/need to do anything with it. (that have a service discovery browser instead of little individual icons like this) It’‘s not something that would force other clients to have to do anything. If they don’‘t want to take advantage of it, that’'s their perogative. If it turned out to be a good idea, it could be proposed as an XEP.

7

jadestorm wrote:

Spark is already doing non-standard things.

Well, that’'s a bad idea.

Point me to where it says the standard says that the items response should be changed based on the requesting client.

Section 6.3 of XEP-0030 says that it’'s possible. The idea behind XMPP is to push complexity to the server, not the client.

Also point me to another server that does -not- implement it like this.

I’'m not familiar with the way this is implemented in any servers.

It would be horribly inefficient for the server to re-request an items list every time someone did a service discovery.

The server does that for every disco to any client, and that’‘s ok? It’‘s even less of an issue with a plugin like yours, since there’'s not network traffic involved, just some local method calls. Even regular gateways are usually on the local machine.

Besides that I’'m not forcing any clients to do anything.

Yeah, just like Microsoft isn’'t forcing anyone to write IE6-compatible web sites.

Clients that work like Psi won’'t care/need to do anything with it. (that have a service discovery browser instead of little individual icons like this)

It would still display useless information in the browser.

If it turned out to be a good idea, it could be proposed as an XEP.

That probably wouldn’‘t be accepted, since it’'s against the spirit of XMPP.

8

anlumo wrote:
jadestorm wrote:

Spark is already doing non-standard things.

Well, that’'s a bad idea.

chuckle Tell Jive that. (that said, the non-standard thing it wants to do in relation to the plugin is something they were talking about pushing towards an XEP)

Point me to where it says the standard says that the items response should be changed based on the requesting client.

Section 6.3 of XEP-0030 says that it’'s possible. The idea behind XMPP is to push complexity to the server, not the client.

Cool, I’‘d never seen that section before, but I still don’'t understand logistically how this would work. (see below)

Also point me to another server that does -not- implement it like this.

I’'m not familiar with the way this is implemented in any servers.

I’‘ve been writing non-Openfire related plugins for many years now and all of them do a disco inquiry the first time the transport connects and then store those results. I think it’'s primarily after the #info list so that it can easily pass on the features/etc of the entities to the client. (but they all seem to ask for #items too)

The whole concept has frustrated me for a long time. I’'ve always wanted the ability to filter/adjust the disco response based on the calling user and the option is just never provided to me. (unless the client -specifically- specifies the transport jid in disco. ie if you do a query to example.jabber.org, the request goes to the server and it answers on behalf of the transports. if you do a query to aim.example.jabber.org the transport itself really does get the opportunity to filter because the query goes directly do it)

It would be horribly inefficient for the server to re-request an items list every time someone did a service discovery.

The server does that for every disco to any client, and that’‘s ok? It’‘s even less of an issue with a plugin like yours, since there’'s not network traffic involved, just some local method calls. Even regular gateways are usually on the local machine.

The server does that between the client and itself. The server does not go “hey 83 components that are connected to me, can you tell me again who you are and what you do?”.

Besides that I’'m not forcing any clients to do anything.

Yeah, just like Microsoft isn’'t forcing anyone to write IE6-compatible web sites.

Just like no one is forcing XEP-XXXX on anyone but it’‘s there. There’‘s a lot of XEPs out there that aren’'t required. Course very little is really required in the land of XEP…

Clients that work like Psi won’'t care/need to do anything with it. (that have a service discovery browser instead of little individual icons like this)

It would still display useless information in the browser.

It already does. If you don’‘t support avatars, then jabber:iq:avatar is useless information displayed to the browser. If you don’'t support jingle then all of the jingle hooha is useless.

If it turned out to be a good idea, it could be proposed as an XEP.

That probably wouldn’‘t be accepted, since it’'s against the spirit of XMPP.

It’‘s really like the same as any other disco response. I do see your point about it pushing the complexity to the client though. Like I said though, I can easily filter if the query is made to the transport itself from the client. That’‘s easy. But that’'s not how things work.

If you’‘ve got better suggestions I’'m all ears.

Daniel

9

jadestorm wrote:

anlumo wrote:
Also point me to another server that does -not- implement it like this.

I’'m not familiar with the way this is implemented in any servers.

I’‘ve been writing non-Openfire related plugins for many years now and all of them do a disco inquiry the first time the transport connects and then store those results. I think it’'s primarily after the #info list so that it can easily pass on the features/etc of the entities to the client. (but they all seem to ask for #items too)

That’‘s not a requirement of the spec, though, right? Just because all the servers use the caching route doesn’‘t mean that it’'s a standard.

The server does that for every disco to any client, and that’‘s ok? It’‘s even less of an issue with a plugin like yours, since there’'s not network traffic involved, just some local method calls. Even regular gateways are usually on the local machine.

The server does that between the client and itself. The server does not go “hey 83 components that are connected to me, can you tell me again who you are and what you do?”.

But it could do that, and still be compliant to the disco-XEP.

Yeah, just like Microsoft isn’'t forcing anyone to write IE6-compatible web sites.

Just like no one is forcing XEP-XXXX on anyone but it’‘s there. There’‘s a lot of XEPs out there that aren’'t required. Course very little is really required in the land of XEP…

Yes, but customers tend to ask for that kind of stuff.

It would still display useless information in the browser.

It already does. If you don’‘t support avatars, then jabber:iq:avatar is useless information displayed to the browser. If you don’'t support jingle then all of the jingle hooha is useless.

jabber:iq:avatar is never displayed to the user. Plus, you can filter on services you know how to handle in that disco#items-reply. That doesn’'t help in this case, since the client most likely knows how to handle gateways.

It’‘s really like the same as any other disco response. I do see your point about it pushing the complexity to the client though. Like I said though, I can easily filter if the query is made to the transport itself from the client. That’‘s easy. But that’'s not how things work.

If you’‘ve got better suggestions I’'m all ears.

You’‘re not writing a gateway, you’‘re writing a plugin. Couldn’‘t you just install a general packet interceptor on those disco-requests and handle them yourself, overriding Openfire’'s default behavior?

10

I’‘ve been writing non-Openfire related plugins for many years now and all of them do a disco inquiry the first time the transport connects and then store those results. I think it’'s primarily after the #info list so that it can easily pass on the features/etc of the entities to the client. (but they all seem to ask for #items too)

That’‘s not a requirement of the spec, though, right? Just because all the servers use the caching route doesn’‘t mean that it’'s a standard.

You know, I have no idea actually! I -believe- I recall reading somewhere that this was proper behavior though. (ie, I believe I remember reading almost the exact words of “after the component connects, the server performs a disco items and info request which the server SHOULD relay to requesting clients”. But did I read that in a forum /mailing list post or an actual spec? I do not know. Those words are grafted in my memory though. That said, it may be moot. See later …

The server does that between the client and itself. The server does not go “hey 83 components that are connected to me, can you tell me again who you are and what you do?”.

But it could do that, and still be compliant to the disco-XEP.

Perhaps. If what I thought was the case above it violated some other XEP, not disco’‘s own. (I definitely recall none of this being discussed directly in the disco XEP btw, I thought it was XEP-0100 but I can’'t find it) Then again things have changed, I may be remembering something from an earlier revision. Hell I could be misremembering entirely.

Just like no one is forcing XEP-XXXX on anyone but it’‘s there. There’‘s a lot of XEPs out there that aren’'t required. Course very little is really required in the land of XEP…

Yes, but customers tend to ask for that kind of stuff.

And customers tend to ask for things like easy ways not to see icons.

It already does. If you don’‘t support avatars, then jabber:iq:avatar is useless information displayed to the browser. If you don’'t support jingle then all of the jingle hooha is useless.

jabber:iq:avatar is never displayed to the user. Plus, you can filter on services you know how to handle in that disco#items-reply. That doesn’'t help in this case, since the client most likely knows how to handle gateways.

I don’‘t follow how this “negates” what I was saying. Yes you can filter on jabber:iq:gateway. You can also filter on jabber:iq:register. You could also filter on jabber:iq:registered if you knew to look for it. I have seen jabber:iq:avatar displayed actually, in a service discovery browser of some client. (don’'t recall which)

It’‘s really like the same as any other disco response. I do see your point about it pushing the complexity to the client though. Like I said though, I can easily filter if the query is made to the transport itself from the client. That’‘s easy. But that’'s not how things work.

If you’‘ve got better suggestions I’'m all ears.

You’‘re not writing a gateway, you’‘re writing a plugin. Couldn’‘t you just install a general packet interceptor on those disco-requests and handle them yourself, overriding Openfire’'s default behavior?

Hrm. That’‘s actually not a bad idea. Either doing it your way or a related way. I mean I’‘m not going to try to answer disco requests on behalf of the server, that’‘s getting into ridiculous territory of doing the job that the server should be doing, reinventing the wheel, etc. However I -might- be able to intercept the outgoing disco response and adjust the outgoing xml accordingly. Likewise, another hook could always be thrown in by the Jive folk to allow me a chance to adjust if there’'s not already a way. ponder See GATE-179 Thanks!

11

jadestorm wrote:
Yes, but customers tend to ask for that kind of stuff.

And customers tend to ask for things like easy ways not to see icons.

Customers actually don’‘t care about the way it’‘s implemented It’'s our task to make it as easy as possible for ourselves.

I don’‘t follow how this “negates” what I was saying. Yes you can filter on jabber:iq:gateway. You can also filter on jabber:iq:register. You could also filter on jabber:iq:registered if you knew to look for it. I have seen jabber:iq:avatar displayed actually, in a service discovery browser of some client. (don’'t recall which)

The difference is, even when the client knows how to handle gateways, that doesn’‘t help when it doesn’'t have access to it.

You’‘re not writing a gateway, you’‘re writing a plugin. Couldn’‘t you just install a general packet interceptor on those disco-requests and handle them yourself, overriding Openfire’'s default behavior?

Hrm. That’‘s actually not a bad idea. Either doing it your way or a related way. I mean I’‘m not going to try to answer disco requests on behalf of the server, that’‘s getting into ridiculous territory of doing the job that the server should be doing, reinventing the wheel, etc. However I -might- be able to intercept the outgoing disco response and adjust the outgoing xml accordingly. Likewise, another hook could always be thrown in by the Jive folk to allow me a chance to adjust if there’'s not already a way. ponder See GATE-179 Thanks!

Good to hear