Skip to content
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

Closed
glpatcern opened this issue Jun 23, 2022 · 1 comment
Closed

RFE: make invitation workflow symmetric #55

glpatcern opened this issue Jun 23, 2022 · 1 comment
Assignees

Comments

@glpatcern
Copy link
Member

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.

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.
@glpatcern glpatcern self-assigned this Dec 8, 2022
@glpatcern
Copy link
Member Author

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant