-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Temporary passwords for public non-anonymous protected shares (ie: files shared with an email recipient). #31220
Conversation
apps/files_sharing/lib/BackgroundJob/ResetExpiredPasswordsJob.php
Outdated
Show resolved
Hide resolved
use \OCP\Security\IHasher; | ||
use \OCP\Security\ISecureRandom; | ||
|
||
class ResetExpiredPasswordsJob extends TimedJob { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can ignore these warnings, we'll need to fix the base class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I've a general remark about the necessity of this background job:
I've created another branch (https://github.com/nextcloud/server/commits/enhancement/31005/temporary-passwords-v2), building on this one and adding 2 commits, where password's expiration time is checked in IManager::checkPassword (see 576de4b) hence making this background job unnecessary anymore.
I believe it's a better solution than this background job. Could you please have a look and take a stand?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@StCyr yes, let's use your approach without the background job which checks on-demand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$qb = $this->connection->getQueryBuilder(); | ||
|
||
// QUESTION: DOES THE DATETIME COMPARAISON WORK WELL WHEN TIMEZONES ENTER THE GAME? | ||
// I THINK SO, BECAUSE EVERYTHING HAPPENS ON THE SERVER, HENCE ON THE SAME TZ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually the timezone of server is supposed to be UTC, so should be fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please remove the comment from the code when ready 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the background job idea is discarded => #31220 (comment)
Fixed in 592a1ad. I'm not very fond of this fix -I find it a bit ugly- but it works; I've tried to create a new route to implement this 2-steps authentication ( |
Steps:
Expected result: receive email with new password ======================== I'm sorry I can't reproduce the bug: If I follow the steps precisely, I'm getting automatically authenticated at step 7, rather than being presented with the 'authenticate' page and the "request password" button. So I can't proceed with step 8 and get your actual result. This looks like a normal behaviour to me: After being authenticated for the link (at step 5), I receive a session token which remains valid for some time. So, it's normal that I'm getting automatically authenticated the second time I open the link, isn't? === Vincent: also cannot reproduce any more in 24.0.0, probably it was fixed through a recent change |
emailPrompt.style.display="block"; | ||
|
||
// Hides password prompt | ||
var passwordRequestButton = document.getElementById('request-password-button-not-talk'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/-not-talk/-by-email/ ? 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you want. But, I believe it's best to keep it technology-agnostic for if later we implement other means to request passwords (eg: by sms)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some comments and found some issues, please have a look
lib/public/Share/IManager.php
Outdated
* @return IShare The share object | ||
* @throws \InvalidArgumentException | ||
* @since 9.0.0 | ||
*/ | ||
public function updateShare(IShare $share); | ||
public function updateShare(IShare $share, bool $sendPassword = false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will likely break implementations and might need a new version of the interface
wondering if there's another way by having or deriving this info from the IShare object directly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before adding a new interface let's check if there are really more implementations of IManager or just one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be ok, see #31447
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm.... Anyway, I'm wondering if this new feature (ie: not sending a temporary password upon public authenticate share creation) is really needed... Eventually, it's not that much of an issue if a temporary password is sent to the recipient upon share creation, rather than waiting for the recipient to explicitely requesting it.
I'm thinking about reverting this change. What's your opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are scenarios where one might want to manually set a specific password to make it easier for the other person to type (or it's something they gave them already on paper or another medium), so we should allow for still supporting such scenarios
now, I'm not sure if this applies to this piece of code specifically ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi Cyrille, you're right about misalignment, thanks for spotting
I'll get this clarified internally as this would be a change of behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @StCyr, after a bit of thoughts, we decided we would need a config switch.
Old behaviour would be off by default. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @StCyr, after a bit of thoughts, we decided we would need a config switch. Old behaviour would be off by default. :)
A new checkbox in the share menu?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rather a config switch in config.php to switch it globally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
implemented in c9940b1
I believe the PR is feature complete now. Do you want me to rebase and squash it?
* @param string $identityToken | ||
* @return bool | ||
*/ | ||
protected function validateIdentity(string $identityToken): bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please remove the type hint to allow null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean the @return bool
?
1ae14b4
to
70e790c
Compare
ran php:cs, rebuilt assets, merged suggestions from @CarlSchwan now hoping for green CI |
not that easy
I'll have a look later |
fd1b563
to
94c8c50
Compare
71391aa
to
2aa9885
Compare
Hi @PVince81 @CarlSchwan, I've fixed the unit tests (and added a new one to validate that password is not sent via email when temporary passwords are enabled). Also, the test |
@StCyr thanks a lot! |
…age for shares of type TYPE_EMAIL, when the "video verification" checkbox isn't checked. Users accessing non-anonymous public shares (TYPE_EMAIL shares) can now request a temporary password themselves. - Creates a migration step for the files_sharing app to add the 'password_expiration_time' attribute to the oc_shares table. - Makes share temporary passwords' expiration time configurable via a system value. - Adds a system config value to allow permanent share passwords -Fixes a typo in a comment in apps/files_sharing/src/components/SharingEntryLink.vue See #31005 Signed-off-by: Cyrille Bollu <cyrpub@bollu.be>
f4abed9
to
c6a5c07
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
failing test unrelated and has just been fixed on master merging |
Thanks for your first pull request and welcome to the community! Feel free to keep them coming! If you are looking for issues to tackle then have a look at this selection: https://github.com/nextcloud/server/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 |
seems a bug has sneaked in, the expiration date column never changes for me on master, raised here: #31951 |
and some UX feedback: #31952 |
This PR implements #31005
With this change, passwords protecting public non-anonymous shares become temporary: They have an expiration time and a background job changes them to some random undisclosed value when their expiration time is passed.
To request a new temporary password, recipients use a new "request password" button that is added to protected public non-anonymous shares' authentication page. This button serves the same functionality as the "request password" button implemented by Talk (ie: To identify the person requesting the password), except that, here, the person identifies herself by proving she knows the email address with which the file is shared with (ie: she types her email address, and if it matches the email address with which the file is shared the person is considered "identified" and a new temporary password is sent to that email address). Of course, identification via a Talk session takes precedence when the share has its "video verification" attribute checked.
I'm waiting for your reviews and welcome your comments which I hope will be constructive
Cyrille
===============================
UPDATE 20220217:
===============================
UPDATE 20220223:
I've created a new branch: https://github.com/nextcloud/server/tree/enhancement/31005/temporary-passwords-v2
Compared to this branch, this new branch brings the following: