Sharing a file via email and password protect the link #2357

mightyBroccoli · 2016-11-27T18:57:39Z

Steps to reproduce

upload a file
share it via email
done the email will be send an the link inside will not have any form of security

Expected behavior

I would expect that the nextcloud instance should have the function to password protect the link inside the email.

Actual behavior

The link inside the email will get shared without a password.

Server configuration

Operating system:
Distributor ID: Debian
Description: Debian GNU/Linux 8.6 (jessie)
Release: 8.6
Codename: jessie

Web server:
Server version: Apache/2.4.10 (Debian)
Server built: Sep 15 2016 20:44:43
Server's Module Magic Number: 20120211:37
Server loaded: APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture: 64-bit

Database:
mysql Ver 14.14 Distrib 5.5.53, for debian-linux-gnu (x86_64) using readline 6.3

PHP version:
PHP 7.0.13-1 dotdeb+8.1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.13-1 dotdeb+8.1, Copyright (c) 1999-2016, by Zend Technologies

Nextcloud version: (see Nextcloud admin page)
version: 11.0.0.4
versionstring: 11.0 beta
edition:

Updated from an older Nextcloud/ownCloud or fresh install:
updated nextcloud from 9 > 10 > 11beta

Where did you install Nextcloud from:
official website download signed tar.gz



**List of activated apps:**
<details>
<summary>Enabled:
  - activity: 2.4.1
  - admin_audit: 1.1.0
  - announcementcenter: 3.0.0
  - apporder: 0.3.3
  - audioplayer: 1.3.1
  - calendar: 1.4.1
  - comments: 1.1.0
  - dav: 1.1.1
  - direct_menu: 0.9.3
  - federatedfilesharing: 1.1.1
  - federation: 1.1.1
  - files: 1.6.1
  - files_external: 1.1.2
  - files_pdfviewer: 1.0.1
  - files_retention: 1.0.1
  - files_sharing: 1.1.1
  - files_texteditor: 2.2
  - files_trashbin: 1.1.0
  - files_versions: 1.4.0
  - files_videoplayer: 1.0.0
  - firstrunwizard: 2.0
  - gallery: 16.0.0
  - logreader: 1.3.1
  - lookup_server_connector: 1.0.0
  - news: 10.0.0
  - nextcloud_announcements: 1.0
  - notifications: 1.0.1
  - password_policy: 1.1.0
  - provisioning_api: 1.1.0
  - serverinfo: 1.1.1
  - sharebymail: 1.0.0
  - systemtags: 1.1.3
  - templateeditor: 0.2
  - theming: 1.1.1
  - twofactor_backupcodes: 1.0.0
  - twofactor_totp: true
  - updatenotification: 1.1.1
  - workflowengine: 1.1.1
</summary>
</details>

**The content of config/config.php:**
<details>
<summary>Config report</summary>

"system": {
    "instanceid": "ocdwzxwi729i",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "cloud.magicbroccoli.de"
    ],
    "datadirectory": "\/var\/www\/magicbroccoli.de\/data",
    "version": "11.0.0.4",
    "installed": true,
    "cipher": "AES-256-CFB",
    "dbtype": "mysql",
    "dbname": "nextcloud",
    "dbhost": "localhost",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "default_language": "de",
    "defaultapp": "files",
    "enable_avatars": true,
    "allow_user_to_change_display_name": true,
    "remember_login_cookie_lifetime": 1296000,
    "session_lifetime": 86400,
    "auth.bruteforce.protection.enabled": true,
    "mail_smtpmode": "smtp",
    "mail_from_address": "nextcloud",
    "mail_domain": "magicbroccoli.de",
    "mail_smtpauth": 1,
    "mail_smtpauthtype": "LOGIN",
    "mail_smtphost": "mail.server-speed.net",
    "mail_smtpport": "587",
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpsecure": "tls",
    "updatechecker": true,
    "updater.server.url": "https:\/\/updates.nextcloud.org\/server\/",
    "upgrade.disable-web": false,
    "has_internet_connection": true,
    "check_for_working_htaccess": true,
    "check_for_working_webdav": true,
    "check_for_working_wellknown_setup": true,
    "logdateformat": "d.m.Y - H:i:s",
    "logtimezone": "Europe\/Berlin",
    "log_rotate_size": 52428800,
    "loglevel": 2,
    "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
    "appstoreenabled": true,
    "appstoreurl": "https:\/\/apps.nextcloud.com\/api\/v0",
    "appstore.experimental.enabled": true,
    "appcodechecker": false,
    "apps_paths": [
        {
            "path": "\/var\/www\/magicbroccoli.de\/nextcloud\/apps",
            "url": "\/apps",
            "writable": true
        }
    ],
    "memcache.local": "\\OC\\Memcache\\APCu",
    "filelocking.enabled": "true",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "\/var\/run\/redis\/redis.sock",
        "port": 0,
        "timeout": 0
    },
    "enable_previews": true,
    "preview_max_x": 1024,
    "preview_max_y": 1024,
    "preview_max_filesize_image": 25,
    "overwrite.cli.url": "https:\/\/cloud.magicbroccoli.de",
    "htaccess.RewriteBase": "\/",
    "trashbin_retention_obligation": "auto, 60",
    "versions_retention_obligation": "auto",
    "activity_expire_days": 80,
    "filesystem_check_changes": 0,
    "theme": "",
    "maintenance": false,
    "singleuser": false,
    "updater.release.channel": "beta"

</details>

**Are you using external storage, if yes which one:** local/smb/sftp/...
yes local,nextcloud,Google,Dropbox,nfs

**Are you using encryption:** yes/no
no

**Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/...
no

The text was updated successfully, but these errors were encountered:

MorrisJobke · 2016-11-28T09:50:21Z

cc @schiessle @jancborchardt

nickvergessen · 2016-11-28T11:33:37Z

I kind of agree

mightyBroccoli · 2016-11-28T11:45:55Z

A password to additionally protect the link would be perfect. I hope this idea will get implemented would be much easier to just send via email then generate a password protected link and sending that link via email.
👍

schiessle · 2016-11-28T14:30:50Z

The question is how do you get the password to the recipient of the mail? If you write the password to the same mail it doesn't add any additional security. If you expect that people will share it on a different channel you will create a lot of confusion for many users because most expect that they just send out the mail and are done.

mightyBroccoli · 2016-11-28T14:54:07Z

If you expect that people will share it on a different channel you will create a lot of confusion for many users because most expect that they just send out the mail and are done.

To get the password to the recipient of the mail is up to the user. But what is the point of allowing the user the ability to share a link with or without a password and not the same option when sharing via email and the important part is option. The confusion could happen when it's enforced but the same problem is present with the password protected link there the sender has to come around the same problem.

The idea is to just give the option to protect the link inside the mail.
That feature would allow the user to choose. Depends on the use case but in some cases it is necessary to have a password protected link inside the mail so not just anybody opening a simple email can access the shared files. Sure it does not open any additional security if the user send the password and the link inside the same mail but there are so many messengers out there to notify the recipient about the password.

schiessle · 2016-11-28T15:33:15Z

I'm quite sure that if we allow you to set a password but don't send it by mail one of the next request/bug report would be "I send a share to my friend and he can't open it. Why is the password not part of the mail?" And then? Should we then add a option to add the password to the mail or not (even if it makes absolutely no sense to add it to the same mail and would just increase the setting nightmare we already have for sharing)?

In my opinion a mail is a "secure enough" way to get the link to exactly the person it belong to. I know that everyone can intercept a mail, etc. But reality is that today most people either attach the file they want to share directly to the mail (and don't encrypt the mail!) or create a share link and send it by mail (most of the time without a password and if they set one they put it in the same mail). I don't consider it really useful for the majority of the users to send a file by mail and chose a second path to communicate the password.

Still if @nextcloud/designers have a idea how to integrate it nicely in the UI and we reach a majority who think (can convince me that) it makes sense, I'm happy to implement it.

mightyBroccoli · 2016-11-28T16:22:39Z

I'm quite sure that if we allow you to set a password but don't send it by mail one of the next request/bug report would be "I send a share to my friend and he can't open it. Why is the password not part of the mail?" And then? Should we then add a option to add the password to the mail or not (even if it makes absolutely no sense to add it to the same mail and would just increase the setting nightmare we already have for sharing)?

@schiessle I really dont get the point. Sure some people will not get this and complain. But if that is the main goal to not have people complain then you could remove the feature all together. Why grant the ability to password protect a link but not a link inside an email?

I get that most people wont even use it, but as you said the send via email feature is quick and easy and with that i would stay quick and easy and on top of that would add just that tiny layer of security on top.

In my opinion a mail is a "secure enough" way to get the link to exactly the person it belong to.

Depends strongly on the email provider. Lets take google for example every email with a link through gmail gets crawled. Maybe I really dont want that. Email is not secure not at all.

But reality is that today most people either attach the file they want to share directly to the mail (and don't encrypt the mail!) or create a share link and send it by mail (most of the time without a password and if they set one they put it in the same mail).

Isn't nextcloud basic idea to take security in peoples own hands? Allowing such a feature is in my opinion a step in that direction.

I could be wrong though. I would definitely like that feature.

schiessle · 2016-11-28T16:40:31Z

I really dont get the point. Sure some people will not get this and complain. But if that is the main goal to not have people complain then you could remove the feature all together.

No, because as it is now it serves a specific purpose and provides a good workflow and UX for this purpose. As said, I'm open for suggestions how a good workflow and UX could look like if we allow to set a password. At the moment I just don't see how to integrate this in the UI to make it work smoothly and don't confuse people.

schiessle · 2016-11-28T16:51:38Z

While thinking about it... One possible solution could be that we add a "passwort protection" option right next to the share in the "..." menu which allows you to set a password.

Advantage:

You would first share the file and then set the password, so there would be a good "excuse" not to put the password in the same mail.
When a password was set/changed we could even consider to send the password by a separate mail. It would go to the same mail provider, so it wouldn't solve the "evil mail provider" issue but it would make it harder to intercept both mails (like the bank who send you two separate letters, one with your credit card and one with your pin)

Disadvantage:

For a short periode in time the link would be accessible without a password, could be enough for the crawler of a "evil email provider"

LukasReschke · 2016-11-28T16:52:39Z

For a short periode in time the link would be accessible without a password, could be enough for the crawler of a "evil email provider"

Same problem like we have with the file permissions. I'm still an advocate for having a proper sharing dialogue like Dropbox et al have.

Espina2 · 2016-11-28T17:28:48Z

I think that can be more something like this @LukasReschke

schiessle · 2016-11-28T18:49:56Z

nice screenshots @Espina2 what program is this?

In general, please don't hijack this thread. Having a complete other share dialog is not part of this discussion. Please start a new threat for this discussion or, if it exists, reuse an existing one.

Espina2 · 2016-11-28T18:55:51Z

@schiessle sorry, for posting the screenshots here. Its another "dropbox" made in Portugal/Netherlands app. You can check here https://www.quiver.net/ . You just need to sign in and you will have that "dashboard".

Espina2 · 2016-11-28T18:59:37Z

But this screenshots are very similar for example with Asana https://asana.com/ you have to make login to.

enoch85 · 2016-11-28T20:57:20Z

@Espina2 Too many options, I think Dropbox looks better, but not optimal.

mightyBroccoli · 2016-11-28T21:15:24Z

@enoch85 I think so too. Dropboxes UI is simple and easy and I think thats what @schiessle meant with not complicated / confusing

Espina2 · 2016-11-28T21:15:37Z

This have different context, looks better because it focus in a single thing.

Espina2 · 2016-11-28T21:21:25Z

I just want to show how many security layers that specific app have, and how it let you choose every single one. Just that.

mightyBroccoli · 2016-12-06T00:18:03Z

Are there any news or is all hope lost :( ?

MorrisJobke · 2016-12-06T08:05:02Z

@mightyBroccoli Calm down. This ticket is roughly one week old and we are just right before a release. So we don't spend mich time on new features

SamuelBenard · 2016-12-19T23:39:35Z

I think the same feature request was closed more than a month ago
#1214

mightyBroccoli · 2016-12-19T23:46:44Z

@Chagam that is the issue @schiessle looked at. But this issue is more for the feature by itself to even enable users to send encrypted emails with a link inside, but without the password inside.

fism · 2016-12-20T23:53:49Z

Our goal with this software was to be able to provide a "secure file share" hosted on prem due to ITAR/EAR compliance regulations. This software is great and thought it would be the perfect fit for those who want to share a large file, executables, and protected documents. Unfortunately, without this feature, there is no way I will be able to get my clients to use this software. It's already enough extra steps that they need to navigate to a website, upload a file, click share, and enter in a password. Having them then copy the URL and paste it into an email to compose to the recipient is just too much for us to ask for. By providing them any field or option that will allow them to type in a username (and optionally an email or federated cloud) is only confusing unless it has the desired outcome, in this case, by sending the URL as a password protected share. So I guess I am in line as well for this feature, as I was hoping to whip up some quick documentation and put this into production this week, but now it's on hold. Other than that, great product guys, thank you.

NicoP-S · 2016-12-21T10:36:44Z

We are useing nextcloud 10 at the moment. I set up a NC 11 envrionment for testing. And i was wondering about this "email sharing without password thing". In the old version NC 10 i have set the option force password protection. So i am not able to share a file or folder without setting a password. Sharing via mail is possible after setting a password for the share.
In NC 11 i have set force password protection as well but i can sent a mail without setting the password. Seems to me like a step back. Without the feature to send a mail with a protected link the mail feature is useless for us and the users have to create a protected link and paste it in their email client like @fism said that's to much for a user. We will stay at nextcloud 10 because the mail sharing with password protection is working there fine. I hope Nextcloud 11 will get this feature back.

mightyBroccoli · 2017-01-11T11:17:21Z

Any news on this issue?

ccghad · 2017-01-12T14:40:31Z

As @NicoP-S mentioned in NC10 the behavior was exactly like what @mightyBroccoli wants it to be.

So why not bring it back but possibly as an additional option in 'Admin-->Sharing'? The functionality was already there after all.

As the Mail is sent without interaction there is no chance to add the password to the (initial) outgoing Mail. So the user has to find himself a way to give the password to the recepient.

jancborchardt · 2017-01-12T16:06:02Z

@schiessle UI-wise, we could simply integrate it in the 3-dot menu as an entry »Password protect«. Then inserting an input field (much like we do for sharing a call via link in our Spreed calls app).

d1ffuser · 2017-04-07T16:52:08Z

The "Share via Users, Groups, Email..." textfield should be greyed out (locked) until a password is set, if the "enforce Password protection" option is enabled.

You click on the share symbol.
You enter a password.
Then the textfield for users and email addresses is unlocked.

Seems simple enough.

I still think the share dialogue needs a major overhaul. It's one of the most important features of NC and needs to as simple and straightforward as possible, while giving you all the options you need.
A comment/message field is a must (as seen here: here or here) and solves multiple headaches. Also when sharing internally or via email, there should be a "Share" button that finalizes the changes and gives the user visual feedback, that emails have been send etc.

TeeDizzle · 2017-04-07T23:01:01Z

@schiessle: First of all I'd really like to thank you (and all other contributors) for the effort you put into bringing back the lost features.

The only caveats remaining:

Not being able to set the password before sending the link via webmailer. Actually the same applies to sharing a link - here it will also be published immediately with the possibility to adjust sharing options (passwords, expiration) afterwards. Not tyring to be picky - but if you choose to password protect anything you want to be able to protect it from the beginning on. Anything else is a design flaw, even if it is very comfortable to use and looks nice. If you think of an automated email link harvesting scenario (the evil provider striking again ;) the link may very well be targeted before the user is able to set a password. There should be additional "send" and "publish" buttons for each approach to finalize your actions (I am aware this does not comply to the current UI implementation). Can you think of any password protected ressource or account creation where you set the password afterwards, even seconds later? I can't. Don't get me wrong, I can personally live with the improved implementation and I am glad you all chose to put this back in. But this still has to be said.
The issues brought up by @supremesyntax regarding site wide password enforcement.

schiessle · 2017-04-10T10:59:17Z

The "Share via Users, Groups, Email..." textfield should be greyed out (locked) until a password is set, if the "enforce Password protection" option is enabled.

No, because if you want to share with a user/group or do a federated share you don't want to add a password first because it is not used anyway.

d1ffuser · 2017-04-10T11:03:03Z

Then the email textfield could be separated from internal/federated users/groups.
Alternatively there could be a publish/share button that verifies the settings etc. (i.e. examples above).

nickvergessen · 2017-04-10T11:09:03Z

Could also just delay the sending with setTimeout() for about 1 minute. And if the password has been set fire of immediately.

schiessle · 2017-04-10T12:41:43Z

Could also just delay the sending with setTimeout() for about 1 minute. And if the password has been set fire of immediately.

The drawback: The user doesn't has a immediate feedback in case of a failure, e.g. because the smtp server isn't configured correctly.

schiessle · 2017-04-10T12:44:42Z

@hgooijen

So, why not generate a strong password and password protect the link in the email? I don't realy care what the password is, as long as it's protected.

This sounds like a interesting approach and could be implemented relatively easy but it only works as long as the admin didn't disabled the "send password by mail" option.

If i would like to know the password, i can share it a second time and provide a self made password.

If you want your custom password you wouldn't need to re-share. Just go to the permission drop down and set your new password

If someone has a good idea what to do in case "send password by mail" was disabled I might go ahead and implement it. 😉

mightyBroccoli · 2017-04-10T13:02:15Z

If someone has a good idea what to do in case "send password by mail" was disabled I might go ahead and implement it. 😉

Why implement something overly fancy. Thats what this issue originally was about. To have the ability to send an automatic email with a link and the password to that link, could be randomized could be set by the user, is send by the user. Through what ever telegram whats app mail or eg there area millions of messengers out there. This feature is just to grant that tiny little barrier around that link.

schiessle · 2017-04-10T13:35:42Z

Why implement something overly fancy.

I don' think it is "overly fancy". Actually it is straight forward. Most people don't want to care about how to send a password from A to B. They just want it to work (tm). That's why by default we send the password in a separate mail. It is easy to send a random generated password in case of password protection is enforced. Actually I really like this approach. Because this way the user don't have to care. They don't have to set a password manually, they don't need to fight with the password policy app until the password is secure enough, and the share is still protected by a additional password.

BUT as said, it doesn't work if the admin disables the password mail. In this case we need to display the user something like "Mail was shared with Password: xyz". We could re-use the yellow banner at the top. But I don't really like it. Or we add it to the share list directly below the users email address, on page reload it will disappear. On the other hand I can imagine that people don't like it at all that a password is displayed on the screen. Another idea: In this case we could send the password by mail not to the recipient of the share but to the user who created the share. Since we never send the link to the owner this would be completely decoupled and from there the owner of the share could decide how to distribute the password. But will a "normal" office worker understand this workflow? In this case I could even imagine that most people would just forward the mail to the recipient of the share, so nothing won beside more complexity.

schiessle · 2017-04-10T14:51:20Z

hm, maybe a banner doesn't look that bad:

It is anyway a quite specific use case: password required & password email disabled

mightyBroccoli · 2017-04-10T15:23:56Z

Ok maybe I was on the wrong train all together :D
Your approach to display the password with a banner is brilliant. In that specific case thats all the user needs to know. I think this is possibly the solution to this issue.

supremesyntax · 2017-04-10T15:48:33Z

Another idea: In this case we could send the password by mail not to the recipient of the share but to the user who created the share. Since we never send the link to the owner this would be completely decoupled and from there the owner of the share could decide how to distribute the password.

i actually like that idea very much. you could send some info inside that e-mail to the owner that sharing the password on a second channel would be more secure and this step was enforced by the admin if so...

schiessle · 2017-04-11T10:33:46Z

Yesterday evening I started to hack a prove of concept. Therefore I discovered two issues:

The banner solution (Sharing a file via email and password protect the link #2357 (comment)) is bad, because it only work on the web interface. We need something which works on the desktop and mobile clients as well without a lot of extra work.
So I started to implement the idea that the password gets mailed to the person who created the share. Challenge: What do we do if the user doesn't have a password? Fall back to "no password by default", this would be bad. If the admin requires a password we shouldn't bypass it. Or we simply fail with a error message that you should set a email address in the personal settings. This would allow us to finish in a defined way, but I don't really like it. It is probably a really small group of people who don't have a email set because you also need it for password reset, etc. But still something we need to deal with.

supremesyntax · 2017-04-11T11:33:36Z

Despite the work already done which is great after some thinking i agree with @d1ffuser

I still think the share dialogue needs a major overhaul.

The most elegant solution would be to not automatically share (and send e-mail) after hitting the enter key but to leave the choice to the user when to activate it e.g with an extra share button on the bottom.
I know that this would also mean big changes in logic and also in mobile/desktop apps...

Steps would be as below:

Enter a recipient (could be user/group/e-mail/federated) in the input field
After hitting enter trigger the share dialogue but don't do anything in background
User sets everything he needs or enforced by admin (expiration date/password/permissions)
Hit a [share] button which finally activates the share and triggers all events
(check if all enforced requirements are met/check smtp/send e-mail/write to database etc.).
If anything is not successful/missing show error message(s) below respective input fields and give the user info what is missing and why he has to set it.

You would not need a automatically generated password and no object could be shared without password (when enforced) as the checks/processes are done only when hitting the share button. If any error occurs nothing is shared until the user is correcting it.

This would be the ideal work-flow for all my needs 😃 It would require an extra step for the user (hitting [share]) but would mean an additional step towards security.

You could also combine this with a pre-generated password if the 'enforce password' setting is enabled and add a icon besides the password field which generates a random password respecting the password requirements in admin settings hence give the user the choice to use it if not enforced.

@schiessle

Or we simply fail with a error message that you should set a email address in the personal settings.

Ignoring my comment above i would say this would be the most reasonable way to go.

schiessle · 2017-04-11T13:11:57Z

@supremesyntax sorry, but a new share dialog is completely out of scope for now. Bringing it up again-and-again doesn't make it more likely to happen. We can try to make "enforce password protection" happen within the overall design we have now or not. I proposed here what I already have, feel free to have a look and give feedback: #4303

d1ffuser · 2017-04-11T14:50:19Z

@schiessle relax, no one is twisting your arm :)
I think your solution is a very good compromise for the time being.
Down the road, a redesign is inevitable, if nextcloud wants to offer usability comparable to established cloud services. Bringing up a more elaborate solution is therefore not without reason.

schiessle · 2017-04-11T15:10:19Z

relax, no one is twisting your arm :)

Don't worry. I just want to make this clear because I prefer to work on pragmatic solution which could make it in Nc12 with all the people involved in this issue. No offense taken. 😃

schiessle · 2017-04-11T15:15:23Z

And before I forget to mention it. I really like the discussion here! I think we achieved a lot and with all the great ideas we discussed, we found quite some nice solutions! 😃

supremesyntax · 2017-04-11T15:29:24Z

@schiessle
Understood.

I will have a look at #4303 👍

hgooijen · 2017-04-11T21:28:51Z

maybe i'm a bit ignorant, but why should the user be informed about what the auto generated password is? whats the user going to do with that password?
when sending a mail, the password will be send in the mail by a password protected link. If the user actually does want to know the password, he/she can click the "sharelink" checkbox and set a password as a new share?
I don't understand why the user should be informed of the password which is send by a mail which he/she want's to directly mail to someone....

schiessle · 2017-04-12T14:20:16Z

@hgooijen It is the "scenario 2" described here: #4303 In case we don't allow to send the password to the recipient we send it to the owner so that he (a) knows the password and (b) knows that further action is needed. Otherwise we end up with a share, protected with a password nobody knows. And I see already angry users:

UserA: "Hey you send me a link and it doesn't work"
UserB: "What doesn't work"
UserA: "It ask for a password, what should I enter?"
UserB: "No idee, I didn't set a password... let me check"
UserB: "...oh, indeed there is a password set and I can't remove it"
UserB "... stupid software, I will send you the file by mail"

We need to guide the users. We can't expect that they know all the details we discuss here and how the admin configured the server.

mightyBroccoli · 2017-04-12T14:32:45Z

@hgooijen I think you did not get what this whole issue is about. The whole reason why we are discussing this is to enable the user to send a password protected link a with the password along side the mail or b with the password known to the user so he can spread the mail and then send the password per mail bird or what ever.

I fully understand @schiessle here. The outrage would be more like noone would use such a feature and then this whole conversation is obsolete.

MorrisJobke added enhancement feature: sharing 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Nov 28, 2016

MorrisJobke closed this as completed in #4136 Apr 7, 2017

MorrisJobke added this to the Nextcloud 12.0 milestone Apr 7, 2017

schiessle mentioned this issue Apr 11, 2017

allow admin to enforce password on mail shares #4303

Merged

nextcloud-bot mentioned this issue Jun 21, 2018

All files get Password protected if user saves password on the browser #9950

Closed

nextcloud-bot mentioned this issue Aug 10, 2018

Link sharing broken with enforced password protection #10644

Closed

nextcloud-bot mentioned this issue Sep 29, 2018

the "share by direct link" option for files that in usually under the "share by email" is gone #11450

Closed

nextcloud-bot mentioned this issue Oct 9, 2018

Sharing a password protected file with a note by mail generates three mails #11694

Closed

nextcloud-bot mentioned this issue Nov 20, 2018

Password protect button on link shares is too wide #12557

Closed

Sharing a file via email and password protect the link #2357

Sharing a file via email and password protect the link #2357

Comments

mightyBroccoli commented Nov 27, 2016

Steps to reproduce

Expected behavior

Actual behavior

Server configuration

MorrisJobke commented Nov 28, 2016

nickvergessen commented Nov 28, 2016

mightyBroccoli commented Nov 28, 2016

schiessle commented Nov 28, 2016 • edited Loading

mightyBroccoli commented Nov 28, 2016 • edited Loading

schiessle commented Nov 28, 2016 • edited Loading

mightyBroccoli commented Nov 28, 2016

schiessle commented Nov 28, 2016 • edited Loading

schiessle commented Nov 28, 2016 • edited Loading

LukasReschke commented Nov 28, 2016 • edited Loading

Espina2 commented Nov 28, 2016

schiessle commented Nov 28, 2016 • edited Loading

Espina2 commented Nov 28, 2016

Espina2 commented Nov 28, 2016

enoch85 commented Nov 28, 2016

mightyBroccoli commented Nov 28, 2016

Espina2 commented Nov 28, 2016

Espina2 commented Nov 28, 2016 • edited Loading

mightyBroccoli commented Dec 6, 2016

MorrisJobke commented Dec 6, 2016

SamuelBenard commented Dec 19, 2016

mightyBroccoli commented Dec 19, 2016

fism commented Dec 20, 2016

NicoP-S commented Dec 21, 2016

mightyBroccoli commented Jan 11, 2017

ccghad commented Jan 12, 2017

jancborchardt commented Jan 12, 2017

d1ffuser commented Apr 7, 2017

TeeDizzle commented Apr 7, 2017

schiessle commented Apr 10, 2017

d1ffuser commented Apr 10, 2017

nickvergessen commented Apr 10, 2017

schiessle commented Apr 10, 2017

schiessle commented Apr 10, 2017 • edited Loading

mightyBroccoli commented Apr 10, 2017

schiessle commented Apr 10, 2017 • edited Loading

schiessle commented Apr 10, 2017 • edited Loading

mightyBroccoli commented Apr 10, 2017

supremesyntax commented Apr 10, 2017 • edited Loading

schiessle commented Apr 11, 2017 • edited Loading

supremesyntax commented Apr 11, 2017 • edited Loading

schiessle commented Apr 11, 2017 • edited Loading

d1ffuser commented Apr 11, 2017

schiessle commented Apr 11, 2017

schiessle commented Apr 11, 2017

supremesyntax commented Apr 11, 2017

hgooijen commented Apr 11, 2017

schiessle commented Apr 12, 2017 • edited Loading

mightyBroccoli commented Apr 12, 2017

schiessle commented Nov 28, 2016 •

edited

Loading

mightyBroccoli commented Nov 28, 2016 •

edited

Loading

schiessle commented Nov 28, 2016 •

edited

Loading

schiessle commented Nov 28, 2016 •

edited

Loading

schiessle commented Nov 28, 2016 •

edited

Loading

LukasReschke commented Nov 28, 2016 •

edited

Loading

schiessle commented Nov 28, 2016 •

edited

Loading

Espina2 commented Nov 28, 2016 •

edited

Loading

schiessle commented Apr 10, 2017 •

edited

Loading

schiessle commented Apr 10, 2017 •

edited

Loading

schiessle commented Apr 10, 2017 •

edited

Loading

supremesyntax commented Apr 10, 2017 •

edited

Loading

schiessle commented Apr 11, 2017 •

edited

Loading

supremesyntax commented Apr 11, 2017 •

edited

Loading

schiessle commented Apr 11, 2017 •

edited

Loading

schiessle commented Apr 12, 2017 •

edited

Loading