Joas Schilling [Wed, 17 Jun 2020 09:59:56 +0000 (11:59 +0200)]
Move back to IGroupManager::displayNamesInGroup()
The problem is that despite it's name IGroup::searchDisplayName()
only searches by userid and this is less fixable than changing back to this method here
Christoph Wurst [Mon, 15 Jun 2020 07:12:42 +0000 (09:12 +0200)]
Disable Client-Side Monitoring on AWS storage
The S3 client enables this by default and then tries to read
`.aws/config`. This causes `open_basedir` restriction related error for
some setups. So this patch disables the CSM because it's most likely
unused anyway.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Restore previous state when failing to change video verification state
When video verification can not be enabled or disabled the previous
state is set again in the JavaScript share object. This ensures that the
UI will not reflect a misleading state.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com> Signed-off-by: npmbuildbot[bot] <npmbuildbot[bot]@users.noreply.github.com>
Christoph Wurst [Tue, 12 May 2020 09:57:30 +0000 (11:57 +0200)]
Fix the Talk verification
When enabling or disabling Talk verification in mail shares the server
expects also a new password to be set. As we always just update one
property at a time this means the Talk verification was impossible to
activate or deactivate. With this patch, we send the talk option AND the
new password. If there is no new password, the Talk option is disabled
(in mail shares; in link shares it is possible to enable or disable the
video verification without changing the password).
When we finally have descriptive text on ActionCheckbox'es we should
definitely add some explanatory text for the user. Right now this is as
good as it gets.
We'll have to backport to 18.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Christoph Wurst [Tue, 2 Jun 2020 07:21:09 +0000 (09:21 +0200)]
Do not only catch Exceptions but any Throwable during rmt share delete
When a remote share is deleted, we notify the remove instance. This may
trigger various error conditions, which we want to catch in order to
avoid undeletable shares. The try-catch, however, did only capture
exceptions, so things like TypeErrors were not caught and caused the
process to fail hard.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Enabling the "send password by Talk" property of shares require that
Talk is installed and enabled, so the Drone step that runs them has to
first clone the Talk repository.
When the integration tests are run on a local development instance,
however, it is not guaranteed that Talk is installed. Due to this the
"@Talk" tag was added, which ensures that any feature or scenario marked
with it will first check if Talk is installed and, if not, skip the
scenario (instead of failing).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Add integration tests for creating and updating a mail share
In most cases, when a mail share is created or updated an e-mail is sent
to the sharee, which is done by connecting to the SMTP server set in the
configuration. If the server can not be contacted then the creation or
update of the mail share fails.
To make possible to test mail shares without using a real SMTP server a
fake one has been added. The original script, which is MIT licensed, was
based on inetd, so it was slightly modified to run on its own.
In order to use it from the integration tests the "Given dummy mail
server is listening" step has to be called in the scenarios in which the
mail server is needed.
For now that is the only available step; things like checking the sent
mails, while possible (as the script can log the mails to certain file),
have not been added yet.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fix disabling send password by Talk without new password in mail shares
When "send password by Talk" was disabled in a mail share it was
possible to keep the same password as before, as it does not pose any
security issue (unlike keeping it when "send password by Talk" is
enabled, as in that case the password was already disclosed by mail).
However, if a mail share is updated but the password is not set again
only the hashed password will be available. In that case it would not
make sense to send the password by mail, so now the password must be
changed when disabling "send password by Talk".
Note that, even if explicitly setting the same password again along with
the "send password by Talk" property would work, this was also prevented
for simplicity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fix enabling send password by Talk with same password in mail shares
When "send password by Talk" is enabled in a mail share a new password
must be also set. However, when the passwords of the original and the
new share were compared it was not taken into account that the original
password is now hashed, while the new one is not (unless no new password
was sent, in which case the password of the original share was set in
the new share by the controller, but that was already prevented due to
both passwords being literally the same), so it was possible to set the
same password again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a mail share was created with a password the given password was not
hashed, so it was not possible to open the share with that password.
Moreover, if passwords were enforced the given password was ignored and
a new one was set (although in this case it was hashed so it worked as
expected). Now the given password is properly hashed and not overriden.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Enabling the "send password by Talk" property of shares require that
Talk is installed and enabled, so the Drone step that runs them has to
first clone the Talk repository.
When the integration tests are run on a local development instance,
however, it is not guaranteed that Talk is installed. Due to this the
"@Talk" tag was added, which ensures that any feature or scenario marked
with it will first check if Talk is installed and, if not, skip the
scenario (instead of failing).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Add integration tests for creating and updating a mail share
In most cases, when a mail share is created or updated an e-mail is sent
to the sharee, which is done by connecting to the SMTP server set in the
configuration. If the server can not be contacted then the creation or
update of the mail share fails.
To make possible to test mail shares without using a real SMTP server a
fake one has been added. The original script, which is MIT licensed, was
based on inetd, so it was slightly modified to run on its own.
In order to use it from the integration tests the "Given dummy mail
server is listening" step has to be called in the scenarios in which the
mail server is needed.
For now that is the only available step; things like checking the sent
mails, while possible (as the script can log the mails to certain file),
have not been added yet.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fix disabling send password by Talk without new password in mail shares
When "send password by Talk" was disabled in a mail share it was
possible to keep the same password as before, as it does not pose any
security issue (unlike keeping it when "send password by Talk" is
enabled, as in that case the password was already disclosed by mail).
However, if a mail share is updated but the password is not set again
only the hashed password will be available. In that case it would not
make sense to send the password by mail, so now the password must be
changed when disabling "send password by Talk".
Note that, even if explicitly setting the same password again along with
the "send password by Talk" property would work, this was also prevented
for simplicity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fix enabling send password by Talk with same password in mail shares
When "send password by Talk" is enabled in a mail share a new password
must be also set. However, when the passwords of the original and the
new share were compared it was not taken into account that the original
password is now hashed, while the new one is not (unless no new password
was sent, in which case the password of the original share was set in
the new share by the controller, but that was already prevented due to
both passwords being literally the same), so it was possible to set the
same password again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a mail share was created with a password the given password was not
hashed, so it was not possible to open the share with that password.
Moreover, if passwords were enforced the given password was ignored and
a new one was set (although in this case it was hashed so it worked as
expected). Now the given password is properly hashed and not overriden.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
projects / nextcloud-server.git / log