Fix Argument 1 passed to OC\Security\Crypto::decrypt() must be of the type string, null given
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
So fun fact. Chrome considers a redirect after submitting a form part of
the form actions. Since we redirect to a new protocol (nc://login/).
Causing the form submission to work but the redirect failing hard.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
There is no need to log the expcetion of most of the stuff here.
We should properly log them but an exception is excessive.
This moves it to a proper exception which we can catch and then log.
The other exceptions will still be fully logged.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When no timeout was given "show()" used the default timeout of
"OCP.Toast", which is 7 seconds instead of indefinitely as stated in the
documentation of "show()". "showHtml()" should also indefinitely show
the notification if no timeout is given, but due to the strict
comparison the notification was indefinitely shown only when a timeout
of 0 was explicitly given. Now both methods show the notification
indefinitely (or until it is explicitly hidden) when no timeout is
given.
The unit tests did not catch this error because "showHtml()" had no
tests (as before the move to Toastify it was called from "show()" and
thus implicitly tested), and because "show()" verified that "hide()" was
not called after some time; "hide()" is no longer called from "show()"
since "OCP.Toast" is used internally, so the test always passed even if
the notification was indeed hidden. Now the test is based on whether the
element is found or not, and explicit tests were added too for
"showHtml()".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"showTemporary()" when a timeout was given was being tested along with
the "show()" tests; now there are two separate tests when a timeout is
given, one for "showTemporary()" and one for "show()".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Check number of elements instead of if the jQuery object is defined
Tje jQuery object created through "$('#testArea .toastify')" will be
always defined even if no elements were found, so the check does not
really work; instead, it should be checked the number of elements found.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The constructor is called with the userId. However if a user is not
logged in this is null. Which means that we get an exception instead of
this being handled gracefully in the middleware.
There are cleaner solutions. But this is the solution that is the
easiest to apply without lots of work and risk of breaking things
(handling the logged in middleware before initializing the controller
etc).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Nextcloud bot
dependabot-preview[bot]
Julius Härtl
Victor Goff
Daniel Kesselberg
Roeland Jago Douma
John Molakvoæ (skjnldsv)
Marco Ambrosini
Jan-Christoph Borchardt
Daniel Calviño Sánchez