E.g. text documents might contain hundreds of links whose previews need
to get loaded.
Fixes: nextcloud/collectives#1607
Signed-off-by: Jonas <jonas@freesources.org>
Previously there was a different behavior for public shares (link-shares) and internal shares,
if the user disabled the view permission.
The legacy UI for public shares simply "disabled" the context menu and hided all download actions.
With Nextcloud 31 all share types use the consistent permissions attributes,
which simplifies code, but caused a regression: Images can no longer been viewed.
Because on 30 and before the attribute was not set, previews for view-only files
were still allowed. Now with 31 we need a new way to allow "viewing" shares.
So this is allowing previews for those files, but only for internal usage.
This is done by settin a special header, which only works with custom requests,
and not by opening the URL directly.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Calling the public API endpoints will check for matching registered
reference providers that implement `IPublicReferenceProvider` and call
their respective functions. If no matching provider is found, the
default `LinkReferenceProvider` will be used to provide open graph data.
The frontend reference widget components will call these endpoints from
unauthorized sessions, e.g. in public shares.
If present, the sharing token of the origin URL is passed to
`resolveReferencePublic()` as additional information for the reference
provider to determine the access scope. This allows the respective
reference providers to determine whether the origin share has access to
the linked resource.
`getCacheKeyPublic` also gets the sharing token so it can scope the cached
entry to it.
Contributes to #45978
Signed-off-by: Jonas <jonas@freesources.org>
Allow clients to access the new filename validation options
and make frontend name validation possible.
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Kate <26026535+provokateurin@users.noreply.github.com>
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
SSO backends like SAML and OIDC tried a trick to suppress password
confirmations as they are not possible by design. At least for SAML it was
not reliable when existing user backends where used as user repositories.
Now we are setting a special scope with the token, and also make sure that
the scope is taken over when tokens are regenerated.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>