Moore's Mind

Saturday, February 25, 2006

Bug in PeerGroupIssueCredentials

After trying to figure out how this function works for nearly a week now, I've come to the conclusion, its not working as advertised. Part of the problem, is that none of Microsoft's example code uses this function.

There are three ways to use PeerGroupIssueCredentials:

1) PeerGroupIssueCredentials(hGroup, pwzSubjectIdentity, NULL, 0, ppwzInvitation)

In this form, NULL credentials are passed. The information (member data and credentials) stored in the peer database is used. This is a useful way to re-issue a lost invitation.

2) PeerGroupIssueCredentials(hGroup, pwzSubjectIdentity, pCredentialInfo, 0, ppwzInvitation)

In this form, new credentials can be passed in order to generate a new invitation. Typically, this would extend the expiry date of the member or change their role or friendly name. I get a valid invitation. However, when I use this invitation to re-join the group, the updated credentials are not taken.

3) PeerGroupIssueCredentials(hGroup, pwzSubjectIdentity, pCredentialInfo, 1, ppwzInvitation)

Same as 2) except the newly created GMC (invitation) is published to the group and automatically picked up by the member. When the member connects or is connected, I see the PEER_GROUP_EVENT_MEMBER_CHANGED event with changeType=PEER_MEMBER_JOINED. However, again, the updated credentials are not taken.

If anyone has a working example, showing the expiry date of a member being updated correctly using PeerGroupIssueCredentials, I would really appreciate some help.

The other interesting limitation that I came across is that there doesn't appear to be a way to send a change to PEER_MEMBER.pwzAttributes back to the group.


  • At 6:21 PM, Blogger Tripp Parks said…

    How are youtrying to find out that the time was updated? We typically don’t publish records unless we have to, and membership information will only be published in case we publish some record or if the flag to publish presence is true.


Post a Comment

<< Home