Closed smarinier closed 3 weeks ago
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
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
I write the PR if you agree with that
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.
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.
This issue is affecting me severely too. Just displaying the link would cost nothing
bump. Please just show the link in the sharing sidebar... non-https environments are relatively common in local networks.
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.
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)
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
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?
https://github.com/nextcloud/server/pull/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.
Keep cool! There is a simple but incredibly pointless solution. Since the link is displayed as a QR code, you can transfer it to the clipboard using a QR coder reader.
In view of the currently open CVE entries, I can understand that the developers have better things to do than worry about whether the link is displayed or not.
I'm having the same issue, but with HTTPS in full effect. Maybe it's a deeper issue?
Fix in https://github.com/nextcloud/server/pull/49141
PS: Just a heads up, most of the copy buttons we have are also link that can be right clicked and copied.
⚠️ This issue respects the following points: ⚠️
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
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?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Firefox : 118.0 Google Chrome: 117.0.5938.92