Projects tigase _server server-core Issues #275
Pre approve to roster subscribe request (#275)
Matthew M opened 1 decade ago
Due Date
2017-05-22

Does Tigase support this feature of pre-approve in roster? http://xmpp.org/rfcs/rfc6121.html#sub-preapproval

I would like to solve this problem. User A sends a subscription request user B. Once B approves, B would like to add A as buddy too to become mutual friends, e.g., roster type ="both". I think in the real world, most likely two person would become "mutual" buddies.

So it would be nice for A to pre-approves B, while sending subscription request to B, so that A does not have to approve again (manually) when B sends back another subscription request.

Do you know if Tigase supports this? If not, what would be the best way to achieve this: skipping user A's manual approval of subscription from B?

See discussion: https://projects.tigase.org/boards/4/topics/1084

Thanks!

Artur Hefczyc commented 1 decade ago

Wojciech, you worked on something very similar not long ago. Please have a look at it. Could we make modifications to your recent work to support this optional RFC feature?

wojciech.kapcia@tigase.net commented 1 decade ago

There is already a ticket for pre-approving subscription (#1590) planned for the next version.

However your case is a bit different (extends aforementioned) because it entails automatic setting of pre-approved flag.

We implemented a while back something similar - automatic approving subscription and adding contact to roster but again it's not exactly what you need (it doesn't respect others party subscribing to our request and sending request on it's own), you can control it with following settings, either turning it on for particular plugin:

sess-man/plugins-conf/jabber\:iq\:roster/auto-authorize=true
sess-man/plugins-conf/presence/auto-authorize=true

or for bot plugins at one time

sess-man/plugins-conf/auto-authorize=true

Enabling it results in:

  • upon sending by the user subscription request - adding contact to user roster with subscription both, adding user's contact to contact's roster with subscription both, exchanging presence information of contact and user so they can see each other online;

  • upon sending presence with type either unsubscribe or unsubscribed follows rules defined in RFC regarding processing of such stanza (i.e. adjusting subscription type of user/contact) but without forwarding such unsubscribe/unsubscribed stanza to receiving entity to avoid any notifications for the client; however a roster push is generated to reflect changes to presence in user roster in a seamless manner;

  • simply adding item to the roster (i.e. with <iq/> stanza with correct semantics) will also entails automatic subscription between user and the contact in a matter explained above.

(above description use RFC notions for the following terms: user - owner of the roster, contact - item added to the roster).

Bottomline - to meet your description we still need to implement #1590 - pre-approved state and then extend aforementioned mechanism of automatic subscription.

Matthew M commented 1 decade ago

Thanks for the updates! This "automatic subscription" is really cool. In fact, we also tried to implement this, and I wish we had known this plugin early!

The only step missing here for us is the "contact" has to approve such subscription, then it becomes "both" immediately, therefore, as you said, it seems that "pre-approval" is the only missing step here.

Maybe I should describe our final goal here clearly, so there might be another route to achieve it. It's basically something like Facebook (Linked In) friending and de-friending process.

Basically, we should like our system to avoid the roster to be in the states of one-way-subscription, e.g, neither "to" nor "from". If two person becomes buddies, then only state must be "both" at the end. We are able to tweak our clients, so there is no problem to have multiple interactive steps between clients and server to reach the "both" or "none" states, with only one manual approval from one side to become friends. No approval is needed for de-friending.

  1. user can INVITE or REMOVE friends,

  2. contact must MANUALLY approve upon invitation to become friends, and AUTO subscript back to the user

  3. user's client must AUTO approve on the subscription request back from the contact (more user friendly)

  4. Eventually, system has rosters for anyone only in the state of subscription="both" or "none"

  5. Important: XMPP clients have the restrictions of "memoryless" and "network disruption", for example a web BOSH client. The client has to rely on the roster status provided by the server to make decisions. It is completely okay for the client to do many retries to attempt to bring the roster to the final desired state (e.g., any stanza can be lost in either directions).

Based on original XMPP protocol, even without "pre-approval", it is totally fine for the contact client to automatically subscribe back to the user, and user's client can automatically approve, based on some roster states.

However, as due to the network disruption and memoryless of the client, I am stuck in the ambiguous roster state of "subscription=to | from". I am not sure whether this roster state is the middle of subscribe-and-approve process, or it is simply unsubscribed intentionally. Therefore there is no way for the client to automatically bring roster state to either "both" or "none", without customer manual interaction.

This is the main reason I came to ask about the "pre-approval" feature, as I feel this attribute can help the client to distinguish between the aforementioned ambiguous states. But I assume that "pre-approval" allows the roster to switch from "none" to "both" immediately upon the approval of contact (to eliminate any intermediate "from" or "to" states), is this true?

We would appreciate if you have any suggestion or advise to achieve our goals. The end results are pretty simple, just like what's Facebook friending (and de-friending) process: everything is two-way, with a manual approval on one side only. But it seems that XMPP is lack of a simple solution to achieve this popular goal?

Many thanks in advance!

wojciech.kapcia@tigase.net commented 1 decade ago

For the moment you could tweak method tigase.xmpp.impl.Presence.processInSubscribe() to actually forward subscription request to the user and remove automatic generation of subscribed stanza (with automatic authorization turned on). This should result in desired behaviour.

Otherwise to have simpler authentication flow implementing pre-approved (#1590) is needed.

As for the ambiguity of subscription - when the contact is in the middle of subscription process roster item has additional attribute @item ask='subscribe'@.

Artur Hefczyc commented 9 years ago

Is it completed yet? if not how much work it needs to be completed?

wojciech.kapcia@tigase.net commented 9 years ago

Not yet, this is blocked by #1590. Upon finishing it, adding this functionality should take around 4h to implement.

Daniele Ricci commented 9 years ago

I've proposed a patch, please see https://projects.tigase.org/issues/1590#note-22

wojciech.kapcia@tigase.net commented 7 years ago

Is duplicated by #1590.

Referenced from commit 1 year ago
fix #275 - Tigase permanently loses free heap memory if malformed BOSH packets are sent to it.
git-svn-id: file:///home/svn/repos/tigase-server/trunk@2773 7d282ba1-3ae6-0310-8f9b-c9008a0864d2
andrzej.wojcik committed 1 decade ago
issue 1 of 1
Type
New Feature
Priority
Normal
Assignee
RedmineID
1696
Version
tigase-server-8.0.0
Estimation
4h
Issue Votes (0)
Watchers (0)
Reference
tigase/_server/server-core#275
Please wait...
Page is in error, reload to recover