-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: make invitation workflow symmetric #55
Comments
glpatcern
added a commit
to glpatcern/OCM-API
that referenced
this issue
Dec 8, 2022
…@labkode: - The /forward endpoint was removed as it's a local call - The endpoint to notify about an accepted invite is now /invite-accepted and it is the only additional endpoint in this PR. - The response of that endpoint now contains the identity details of the sender, which are safe to be disclosed at this point as the receiver already did. This allows to address issue cs3org#55. - A new protocol `webapp` is added to `/NewShare`, to enable opening files with remote apps. This removes the need of yet another dedicated endpoint.
glpatcern
added a commit
to glpatcern/OCM-API
that referenced
this issue
Dec 8, 2022
…bkode: - The /forward endpoint was removed as it's a local call - The endpoint to notify about an accepted invite is now /invite-accepted and it is the only additional endpoint in this PR. - The response of that endpoint now contains the identity details of the sender, which are safe to be disclosed at this point as the receiver already did. This allows to address issue cs3org#55. - A new protocol `webapp` is added to `/NewShare`, to enable opening files with remote apps. This removes the need of yet another dedicated endpoint.
glpatcern
added a commit
to glpatcern/OCM-API
that referenced
this issue
Dec 8, 2022
- The /forward endpoint was removed as it's a local call - The endpoint to notify about an accepted invite is now /invite-accepted and it is the only additional endpoint in this PR. - The response of that endpoint now contains the identity details of the sender, which are safe to be disclosed at this point as the receiver already did. This allows to address issue cs3org#55. - A new protocol `webapp` is added to `/NewShare`, to enable opening files with remote apps. This removes the need of yet another dedicated endpoint.
This issue will be closed by #54 |
glpatcern
added a commit
that referenced
this issue
Dec 9, 2022
- The /forward endpoint was removed as it's a local call - The endpoint to notify about an accepted invite is now /invite-accepted and it is the only additional endpoint in this PR. - The response of that endpoint now contains the identity details of the sender, which are safe to be disclosed at this point as the receiver already did. This allows to address issue #55. - A new protocol `webapp` is added to `/NewShare`, to enable opening files with remote apps. This removes the need of yet another dedicated endpoint.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current OCM invite/accept workflow to create shares between user A and B is not symmetric, in the sense that once A invited B and B accepted, A can share with B but B is requested to invite A to be able to share to A.
This RFE is to evolve the workflow - currently still to be merged from #54 - such that A can choose a two-way invitation (and implicitly accepts the back invitation from B). As discussed with @michielbdejong this requires to create a "back token" for the back invitation process to take place.
To be further detailed with the exact expected sequence of operations.
The text was updated successfully, but these errors were encountered: