feat: office 365 proxy support
Description
Related Issue
- Fixes <issue_link>
Motivation and Context
How Has This Been Tested?
- test environment:
- test case 1:
- test case 2:
- ...
Screenshots (if appropriate):
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Technical debt
- [ ] Tests only (no source changes)
Checklist:
- [ ] Code changes
- [ ] Unit tests added
- [ ] Acceptance tests added
- [ ] Documentation ticket raised:
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.
@JammingBen I will not finish that before my vacation.
Deliverables from Web
To continue, i would need some information from the web team
- HostEditUrl and HostViewUrl - these urls are the Web Urls where we can access the opened editor in the correct view mode. Like
/external-office365 . @JammingBen has pointed me to https://github.com/owncloud/web/pull/9879/ - Sharing URL which opens the Web App with the opened sidebar ready for sharing
Language codes
The language codes which are accepted by MS are only the long ones like de-DE and en-US. Currently this is implemented as a "workaround" in this PR. Would be nice to get this sorted out with web.
With regards to the proxy envvars, do we have a similar situation as described in Microsoft Office Online / WOPI Integration? We should in any case do some doc work in the collaboration readme...
Note, do we add that to the ocis_full deployment example?
Linking with https://github.com/owncloud/ocis/pull/9827 because it probably should be applied before this PR. In addition to simplify the code, it removes the HostViewURL and HostEditURL from the WOPI context. They're expected to be re-added at some point (probably with this PR).
In addition to that, the connector's methods are now returning a ConnectorResponse which basically includes the expected HTTP status, headers and body (the body is expected to be json-encoded later). New headers added in this PR are expected to be handled within the connector, so the httpAdapter just needs to forward the data. We need to re-adjust the PR to fit it.
For the wopisrc package, note that the PutRelativeFile operation needs to generate a new wopisrc link to the new file. This is currently done in the FileConnector object, but we'll need merge it with the new code in this PR in order to support the wopi proxy. Also note that the PutFile operation is used in the PutRelativeFile operation; I don't think this PR will affect it (we probably don't need to check new information), but we should double-check.
Quality Gate passed
Issues
3 New issues
0 Accepted issues
Measures
0 Security Hotspots
69.3% Coverage on New Code
4.4% Duplication on New Code