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

Issue #75: WOPI proof #79

Merged
merged 26 commits into from
Jan 8, 2025
Merged

Issue #75: WOPI proof #79

merged 26 commits into from
Jan 8, 2025

Conversation

donquixote
Copy link
Collaborator

Fixes #75

This also contains some refactoring of WopiController, moving access checks to the routing layer.
I could split this out but I would prefer not to..

@donquixote donquixote force-pushed the issue-75-wopi-proof branch 6 times, most recently from f37d4ff to 9789290 Compare December 19, 2024 14:59
@donquixote donquixote force-pushed the issue-75-wopi-proof branch 3 times, most recently from a58c0f4 to 6fa5037 Compare December 19, 2024 15:10
src/Access/WopiTimeoutAccessCheck.php Outdated Show resolved Hide resolved
*
* Note that the X-WOPI-Timestamp is in DotNet ticks.
*/
class WopiTimeoutAccessCheck implements AccessInterface {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the end, the timestamp is used also in the other class, and we basically need one single method from here, while we need to duplicate quite a bit of code. Let's merge all into a single class.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One motivation for the split was the distinct service dependencies.
We can fully keep out the crypto stuff from the timeout checker, and we can fully keep out the dotnet time conversion from the proof checker. We get two independent buckets of control flow.
The shared code is the config check and the timestamp header value.

config/install/collabora_online.settings.yml Show resolved Hide resolved
src/Access/WopiProofAccessCheck.php Show resolved Hide resolved
Comment on lines 63 to 65
$assert_session->fieldValueEquals('Disable TLS certificate check for COOL.', '');
$assert_session->fieldValueEquals('Verify proof header and timestamp in incoming WOPI requests.', '1');
$assert_session->fieldValueEquals('Allow COOL to use fullscreen mode.', '1');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's convert this to checkboxChecked/checkboxNotChecked.

tests/src/Unit/CollaboraDiscoveryTest.php Outdated Show resolved Hide resolved
src/Access/WopiProofAccessCheck.php Show resolved Hide resolved

/**
* Service to get a WOPI client url for a given MIME type.
* Service to get a WOPI client URL for a given MIME type.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not true now. This service is now a representation of the Collabora discovery file.

README.md Show resolved Hide resolved

/**
* Service to get a WOPI client url for a given MIME type.
* Service to get a WOPI client URL for a given MIME type.
*/
class CollaboraDiscovery implements CollaboraDiscoveryInterface {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to rethink a bit how this service works. Probably we should gather once per initialization the file from the fetcher?
I would like a class that completely wraps the XML, and the single methods return the parsed information from it, like a sort of value object.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that too. But, once we have a value object, we can't have it respond to config changes etc.
Perhaps this is all ok, but I would like a separate issue to think about this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One idea I had was a proxy object that deals with the config etc and which then creates the value object to delegate calls to.
When the config changes, we could drop the value object and create a new one.
Or, do we actually need that? Do we care if config changes at runtime, or only between requests?

As a compromise we can have a property that has the cached parsed xml, and then a persistent cache for the xml string. TBD.

@donquixote donquixote merged commit 2dc47be into main Jan 8, 2025
3 checks passed
@donquixote donquixote deleted the issue-75-wopi-proof branch January 8, 2025 15:02
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

Successfully merging this pull request may close these issues.

Implement WOPI proof
2 participants