if $var is a model instance, yes, it's a solution.
You can also use DAO::toUpdates to add multiple instances to the update.
DAO::toUpdates([$user1,$user2,$user3]);With flushUpdates, the update of several objects is then done in a single request.
Otherwise, you can save in a foreach, or use the transactions:
DAO::beginTransaction();
foreach ($users as $user){
DAO::save($user);
}
DAO::commit();
Hi @iDenora
The Csrf part is integrated for the session, with a double cookie system.
It is not yet available for form validation : in the next version (soon).
I guess that's what you were interested in.
For the "Remember me" checkbox, if you use Ubiquity AuthControllers, you just have to override the toCookie method (which allows to memorize the user in a cookie), and the fromCookie, which allows to retrieve a user from a cookie :
Just one example:
protected function toCookie($connected) {
return md5($connected->getLogin());
}
protected function fromCookie($cookie) {
$u = DAO::getOne(User::class, 'MD5(login)= ?', false, [
$cookie
]);
return $u;
}see https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2
protected function toCookie($connected) {
do {
$token = new Authtokens();
$token->setUserid($connected->getId());
$saved = DAO::save($token);
} while ($saved === false);
return $token->getSelector() . ':' . $token->getHashedValidator();
}
protected function fromCookie($cookie) {
list ($selector, $validator) = explode(':', $cookie);
$auth = DAO::getOne(Authtokens::class, 'selector= ?', false, [
$selector
]);
if (isset($auth)) {
if (hash_equals($auth->getHashedValidator(), $validator)) {
return DAO::getById(User::class, $auth->getUserid());
}
}
return null;
}
Hi @NoTeefy
Can you create an issue for this? it'll be easier to deal with.
Thank you!
turned out it was my antivirus (Avast) blocking outgoing mails on my development setup...
Do you know what could be causing this? The user defined in the configs has write access and it also performs those updates without any problems if I run the query by hand (cli) @jcheron
$decodedData = json_decode($jsonString, true);
// build obj
$updatedObj = DAO::getOne(Applications::class, $decodedData['changedObj']['id']);
$updatedObj->setMarked($decodedData['changedObj']['marked']);
$updatedObj->setStatus($decodedData['changedObj']['status']);
// update obj in DB
if(DAO::save($updatedObj)) {
$this->return(true, 'updateApplication{} - successfully updated application with id '.$decodedData['changedObj']['id']);
}
else {
$this->return(false, 'updateApplication{} - got an error while trying to update application with id '.$decodedData['changedObj']['id']);
}{"message":"Route found for /api/updateApplication/ : controllers\\MIDDLEWARE_API/updateApplication","context":{"context":"Router","part":"getRouteUrlParts","extra":null},"level":200,"level_name":"INFO","channel":"xxx","datetime":"2020-05-03T16:01:51.841405+00:00","extra":{}}
{"message":"UPDATE `applications` SET `id`= :id,`twitchname`= :twitchname,`surname`= :surname,`socials`= :socials,`age`= :age,`text`= :text,`status`= :status,`marked`= :marked WHERE `id`= :id","context":{"context":"DAOUpdates","part":"update","extra":null},"level":200,"level_name":"INFO","channel":"xxx","datetime":"2020-05-03T16:01:51.865454+00:00","extra":{}}
{"message":"{\"id\":\"2\",\"twitchname\":\"NoTeefy\",\"surname\":\"xxx\",\"socials\":\"https:\\/\\/twitter.com\\/NoTeefy\",\"age\":\"xx\",\"text\":\"nothing to read here\",\"status\":\"-1\",\"marked\":\"1\"}","context":{"context":"DAOUpdates","part":"Key and values","extra":null},"level":200,"level_name":"INFO","channel":"xxx","datetime":"2020-05-03T16:01:51.865502+00:00","extra":{}}· PHP 7.4.4
· Ubiquity devtools (1.2.13)
· Ubiquity 2.3.7
Hi @NoTeefy
These logs are displayed just before the update,
they allow the information to be verified, but do not mean that the request has been passed.
In any case, these logs are consistent and do not reveal any errors.
If there was a problem you should have an extra line with a warning.
Did you try to see if the Models part of the webtools worked for updates?
You can force error reporting in services.php:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);Otherwise, apart from setting a break point on the save call, and then executing it step by step, I don't see what else to do.
Not sure where we'd need to fix that though. If it's not something specified in any Ubiquity routine, it's probably a new database default on MariaDB
2020-05-03T19:27:07.664585Z 22 Query SET AUTOCOMMIT=0
2020-05-03T19:27:07.666606Z 22 Query SELECT `applications`.`id`,`applications`.`twitchname`, ...
2020-05-03T19:27:07.668208Z 22 Query UPDATE `applications` SET `id`= '2',`twitchname`= 'NoTeefy', ...
2020-05-03T19:27:07.669067Z 22 Quit
@NoTeefy , Hello
For your auto-commit problem, we need to isolate the problem.
Can you create a new project,
composer create-project phpmv/ubiquity-project test-autocommitadd your database, generate the classes and tell me if you have the same problem for updates in the models part of the webtools?
at http://127.0.0.1:8090/Admin/models
To disable default routing and have a 404 route, you can add a last route:
class FooController extends ControllerBase {
...
/**
* @route("{url}","priority"=>-1000)
*/
public function route404($url) {
UResponse::setResponseCode(404);
echo "Page {$url} not found!";
}
} /**
* @route("{url}","priority"=>-1000,"requirements"=>["url"=>"(?!(a|A)dmin).*?"])
*/