[Bug]: No clipboard access for non-https NextCloud servers

[smarinier]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Most "copy to clipboard" operations are made using directly the navigator.clipboard:

e.g. : await navigator.clipboard.writeText(this.internalLink)

In fact, navigator.clipboard is "undefined" when nextcloud is not "secured" (https) in modern browsers (Chrome and Firefox). This generates an exception, without user feedback (Sharing Internal Link at least).

I don't think "https" is one prerequisite for NC. And in my case (developer on NextCloud and family user with my local server), i didn't always configure with an auto-generate certificate! (which implies an annoying warning from the browsers).

Don't you think this could be embeded in a function verifying the availability of navigator.clipboard (and may offer the workaround of textarea + document.execCommand('copy') ?

Steps to reproduce

1. Use a local Nextcloud on http
2. Go to Files and select Share icon
3. Try to copy the internal Link

Expected behavior

Error in developer console:

TypeError: navigator.clipboard is undefined
e SharingEntryInternal.vue:87
d runtime.js:24
t runtime.js:267
_ runtime.js:84
Z SharingEntrySimple.vue:20
s SharingEntryInternal.vue:101
copyLink SharingEntryInternal.vue:101
copyLink SharingEntryInternal.vue:101
copyLink SharingEntryInternal.vue:101
click SharingEntryInternal.vue:1
click NcActions.js:2
VueJS 2
click NcActions.js:2
VueJS 63
r files_sharing_tab.js:69

Installation method

Community Manual installation with Archive

Nextcloud Server version

26

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

SQlite

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "sqlite3",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "192.168.0.13"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "version": "26.0.7.0",
        "overwrite.cli.url": "http:\/\/192.168.0.13\/nc26\/",
        "installed": true
    }
}

List of activated Apps

Enabled:
  - activity: 2.18.0
  - circles: 26.0.0
  - cloud_federation_api: 1.9.0
  - comments: 1.16.0
  - contactsinteraction: 1.7.0
  - dashboard: 7.6.0
  - dav: 1.25.0
  - federatedfilesharing: 1.16.0
  - federation: 1.16.0
  - files: 1.21.1
  - files_mindmap: 0.0.29
  - files_pdfviewer: 2.7.0
  - files_rightclick: 1.5.0
  - files_sharing: 1.18.0
  - files_trashbin: 1.16.0
  - files_versions: 1.19.1
  - firstrunwizard: 2.15.0
  - logreader: 2.11.0
  - lookup_server_connector: 1.14.0
  - nextcloud_announcements: 1.15.0
  - notifications: 2.14.0
  - oauth2: 1.14.1
  - password_policy: 1.16.0
  - photos: 2.2.0
  - privacy: 1.10.0
  - provisioning_api: 1.16.0
  - recommendations: 1.5.0
  - related_resources: 1.1.0
  - serverinfo: 1.16.0
  - settings: 1.8.0
  - sharebymail: 1.16.0
  - support: 1.9.0
  - survey_client: 1.14.0
  - systemtags: 1.16.0
  - text: 3.7.2
  - theming: 2.1.1
  - twofactor_backupcodes: 1.15.0
  - updatenotification: 1.16.0
  - user_status: 1.6.0
  - viewer: 1.10.0
  - weather_status: 1.6.0
  - workflowengine: 2.8.0
Disabled:
  - admin_audit: 1.16.0
  - bruteforcesettings: 2.6.0
  - encryption: 2.14.0
  - files_external: 1.18.0
  - suspicious_login: 4.4.0
  - twofactor_totp: 8.0.0
  - user_ldap: 1.16.0

Nextcloud Signing status

File not found

Nextcloud Logs

{"reqId":"YsJHdVm6vtZWbw9Q2LFb","level":3,"time":"2023-09-27T08:46:08+00:00","remoteAddr":"192.168.0.10","user":"admin","app":"index","method":"POST","url":"/nc26/index.php/apps/text/session/sync","message":"OCA\\Text\\Service\\DocumentService::getFileForSession(): Argument #1 ($session) must be of type OCA\\Text\\Db\\Session, bool given, called in /var/www/html/nc26/apps/text/lib/Service/ApiService.php on line 232 in file '/var/www/html/nc26/apps/text/lib/Service/DocumentService.php' line 442","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36","version":"26.0.7.0","exception":{"Exception":"Exception","Message":"OCA\\Text\\Service\\DocumentService::getFileForSession(): Argument #1 ($session) must be of type OCA\\Text\\Db\\Session, bool given, called in /var/www/html/nc26/apps/text/lib/Service/ApiService.php on line 232 in file '/var/www/html/nc26/apps/text/lib/Service/DocumentService.php' line 442","Code":0,"Trace":[{"file":"/var/www/html/nc26/lib/private/AppFramework/App.php","line":183,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/html/nc26/lib/private/Route/Router.php","line":315,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/var/www/html/nc26/lib/base.php","line":1065,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/var/www/html/nc26/index.php","line":36,"function":"handleRequest","class":"OC","type":"::"}],"File":"/var/www/html/nc26/lib/private/AppFramework/Http/Dispatcher.php","Line":169,"Previous":{"Exception":"TypeError","Message":"OCA\\Text\\Service\\DocumentService::getFileForSession(): Argument #1 ($session) must be of type OCA\\Text\\Db\\Session, bool given, called in /var/www/html/nc26/apps/text/lib/Service/ApiService.php on line 232","Code":0,"Trace":[{"file":"/var/www/html/nc26/apps/text/lib/Service/ApiService.php","line":232,"function":"getFileForSession","class":"OCA\\Text\\Service\\DocumentService","type":"->"},{"file":"/var/www/html/nc26/apps/text/lib/Controller/SessionController.php","line":92,"function":"sync","class":"OCA\\Text\\Service\\ApiService","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/nc26/lib/private/AppFramework/Http/Dispatcher.php","line":230,"function":"sync","class":"OCA\\Text\\Controller\\SessionController","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/html/nc26/lib/private/AppFramework/Http/Dispatcher.php","line":137,"function":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/html/nc26/lib/private/AppFramework/App.php","line":183,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/html/nc26/lib/private/Route/Router.php","line":315,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/var/www/html/nc26/lib/base.php","line":1065,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/var/www/html/nc26/index.php","line":36,"function":"handleRequest","class":"OC","type":"::"}],"File":"/var/www/html/nc26/apps/text/lib/Service/DocumentService.php","Line":442},"CustomMessage":"--"}}

Additional info

Firefox : 118.0
Google Chrome: 117.0.5938.92

[joshtrichards]

Duplicate of #36582

There was some talk of temporarily doing a fallback. Unfortunately since this is about browser support even execCommand() isn't an attractive allback at this point:

https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand

[smarinier]

I've read the #36582 discussion. But i don't really understand why it is closed as the final decision does not seem so obvious.

I propose to

• replace native clipboard calls with a nexcloud util function
• embed with a library "clipboard copy" (suggest VueJS: https://vueuse.org/core/useClipboard)
• handle the error with a user feedback

I write the PR if you agree with that

[creatvty]

Stumbled over this, had to laugh at the "solution" of #38915

Why not a least add something like a tooltip / popover with the url to that component? Then people can chose to copy it or not. Like this you can't access the url at all.

[dolorosus]

I would like to agree with the request to display the link.
It is easy to implement and is also not a security risk, as the information is also made available in the QR code.

There are many users who don't need https security because they only access their Nextcloud instance in the local network.
On weak computers (e.g. Raspberry Pies), https also means a significant loss of performance.

Certificates from "Let's encrypt" are not an alternative, as they require a fixed host name and an open port. Many users do not want open ports, but use a VPN for remote access.

[erentar]

This issue is affecting me severely too. Just displaying the link would cost nothing

[rbeier]

bump.
Please just show the link in the sharing sidebar... non-https environments are relatively common in local networks.

[st3iny]

There are many users who don't need https security because they only access their Nextcloud instance in the local network.
On weak computers (e.g. Raspberry Pies), https also means a significant loss of performance.

I'd like to see some benchmarks on that. Sure, the crypto performance on a Pi is poor but you would need to host a considerably big website or Nextcloud instance to actually see the impact. And then you would get other problems because the Pi can't really handle a big Nextcloud instance anyway. So the computational impact of crypto versus the actual application is negligible.

Certificates from "Let's encrypt" are not an alternative, as they require a fixed host name and an open port. Many users do not want open ports, but use a VPN for remote access.

You could simply use a self signed certificate then. Generating it and then trusting it in your browsers is trivial to set up.

[st3iny]

I agree about showing the link in non-secure contexts. Maybe showing a toast when the copying fails could be a good approach. Although this would need to be implemented manually everywhere the clipboard API is used.

All occurrences in server:

apps/federatedfilesharing/src/components/PersonalSettings.vue
150:                    await navigator.clipboard.writeText(this.cloudId)

apps/files/src/views/Settings.vue
171:                    await navigator.clipboard.writeText(this.webdavUrl)

apps/settings/src/components/AuthTokenSetupDialog.vue
160:                            await navigator.clipboard.writeText(this.appPassword)
174:                            await navigator.clipboard.writeText(this.loginName)

apps/files_sharing/src/components/SharingEntryLink.vue
696:                            await navigator.clipboard.writeText(this.shareLink)

apps/files_sharing/src/components/SharingEntryInternal.vue
96:                             await navigator.clipboard.writeText(this.internalLink)

[dolorosus]

Certificates from "Let's encrypt" are not an alternative, as they require a fixed host name and an open port. Many users do not want open ports, but use a VPN for remote access.

You could simply use a self signed certificate then. Generating it and then trusting it in your browsers is trivial to set up.

Well, what is easy depends on the individual level of knowledge.
What is “easy” for you may be difficult for others. To make it clear to you: It is easy for me to compose a fugue in the style of Bach, is it easy for you or your mother or...?

With the self-signed certificate, you haven't thought things through to the end.
A self-signed certificate requires the CA-certificate to be included in the certificate management of every client. Especially with some Android devices (e.g. Fire Tablets) this is quite “sporty”. Not to mention browsers with their own certificate management (e.g. Firefox).
All in all, the effort required increases with the number of clients.

BTW: The same information is already displayed in the QR code.
The only thing missing is the information as copyable text below or above the QR code. That should be all.

Best wishes

[krysopath]

I second that. I have a particularly complicated setup where I use nx to store microscopy raw images. I just chose NX because it is simple and costs me little to no time. My time is better spent on denoising algorithms, than forcing a variety of friends to install a custom CA, which for private matters is strongly discouraged. Having your friends custom CA trusted in your mobile device opens you up against several juicy attacks.

nextclouds are often used in private network ranges, and lets encrypt has no use case there.

So a custom selfmaintained CA is completely overblown & risky for the average user and Lets encrypt is no good within private networks.

This feature is broken from my pov.

It does happen today with latest Nextcloud Hub 8 (29.0.2) and Overview is telling me this:

You may call it advice, but actually is it coercion? Why break an essential feature? Do you make assumptions about me & how I should deploy nextcloud?

I'd like to see some benchmarks on that. Sure, the crypto performance on a Pi is poor but you would need to host a considerably big website or Nextcloud instance to actually see the impact. And then you would get other problems because the Pi can't really handle a big Nextcloud instance anyway. So the computational impact of crypto versus the actual application is negligible.

@st3iny Lets make an excursion into the lands of logic and technology together. There is a computer that is weak. The computer runs many programs. No nextcloud is not the only service a computer runs, in fact it is not even a service on that device. You were missing an essential piece of HTTP: the client. Even weaker than a RaspberryPi, but you say that it is completely fair to force this client to run a 2nd layer of crypto because of "reasons". I am not sure whether you are grossly simplfiying or misrepresenting the problem. When crypto is load and resource are limited, then doing extra load is bad and it does not matter at all, whether you run nx service on the same device or not.

On a different issue, people say that this due to a browser restriction that is new - forgive me tho, this is bonkers. Nextcloud writes a backend server, which can do arbitrary things. For example it is able to return a string to the client, which is completely ignoring the browser. Nextcloud seems to not be not on top of the tech.. or they believe to fool a technical audience? Intentional gaslighting?

#38915 (closed without discourse and locked last year)

What matters in fact is that somebody went ahead, made assumptions and took away this decision. Patronizingly redirecting me to docs, where I can read 08-15 "HTTPS so important disclaimer", but no actual config option where the behavior can be tweaked. An relative shortcoming of nextcloud product planning and here instead we get absolute security theater in a thread, but not fixing the underlying bug:

narrowly scoped decision-making has removed choice and your users call it bug. sharelinks are broken with http proto. the inability to find a different solution than navigator.clipboard is not because of a browser change. It was a decision by nextcloud to not implement a substitute, after browser api changed and that silently causing a major bug in a past release. Now this all looks like an accident and no sugarcoating/gaslighting about browser frontends will change that.

Have reason to hide the url. when right next a qr code with the link is shown? No? Then why tell stories about technical reasons. Implement a substitute and fix it.

I doubt that is the intention. So here is some feedback. Now, lets say it became too much of an effort to jump through imaginary hoops, then yes I will stop using nextcloud, because it quite obviously does not fit my use case, and I am not a clown.