Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Společnost OpenAI představila text-to-video AI model Sora 2 pro generování realistických videí z textového popisu. Přesnější, realističtější a lépe ovladatelný než předchozí modely. Nabízí také synchronizované dialogy a zvukové efekty.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.0, tj. první stabilní vydání založené na Ubuntu 24.04 LTS.
Rakouská armáda přechází na LibreOffice. Ne kvůli licencím (16 000 počítačů). Hlavním důvodem je digitální suverenita. Prezentace v pdf z LibreOffice Conference 2025.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) upozorňuje na sérii kritických zranitelností v Cisco Adaptive Security Appliance (ASA) a Firepower Threat Defense (FTD) a Cisco IOS, CVE-2025-20333, CVE-2025-20363 a CVE-2025-20362. Zneužití těchto zranitelností může umožnit vzdálenému neautentizovanému útočníkovi spustit libovolný kód (RCE). Společnost Cisco uvedla, že si je vědoma aktivního zneužívání těchto zranitelností.
Ochrana uživatelů a zároveň příznivé podmínky pro rozvoj umělé inteligence (AI). Ministerstvo průmyslu a obchodu (MPO) připravilo minimalistický návrh implementace evropského nařízení o umělé inteligenci, tzv. AI aktu. Český zákon zajišťuje ochranu občanům a bezpečné používání AI, ale zároveň vytváří pro-inovační prostředí, ve kterém se může AI naplno rozvíjet, firmy mohou využít jeho potenciál a nebudou zatíženy zbytečnou administrativou. Návrh je nyní v meziresortním připomínkovém řízení.
Dle plánu Linus Torvalds odstranil souborový systém bcachefs z mainline Linuxu. Tvůrce bcachefs Kent Overstreet na Patreonu informuje, že bcachefs je nově distribuován jako DKMS modul.
Minule jsem stručně popsal autentizaci, dnes, opět krátce, o autorizaci. Autorizace je v Zendu řešena přes Access Controll List (ACL). Je to v podstatě seznam zdrojů (objekt, vůči němuž se kontroluje oprávnění k přístupu), rolí (objekty, které žádají o přístup ke zdrojům) a pravidel definovaných mezi nimi. ACL je v Zendu reprezentován třídou Zend_Acl
, která obsahuje metody pro přidávání zdrojů, rolí, pravidel přístupu a dotazování se na oprávněnost přístupu. Role i zdroje mohou být jak existující objekty, tak objekty, které v systému reálně neexistují (jak bylo řečeno, ACL je seznam nějakých rolí a zdrojů a vztahů mezi nimi, bez jakéhokoli zřetele ne realitu; co si nadefinujeme, to máme).
Prvně tedy musíme definovat zdroje a role, které v systému budou vystupovat. Uvažujme jednoduchý příklad, kdy budeme mít např. školní systém pro zadávání a zobrazování známek. Budeme v systému mít následující role: studen (student), rodiče (parents), učitel (teacher) a administrátor (admin). Zdroje budou reprezentovat jednotlivé případy použití (use case), které budou odpovídat jednotlivým kontrolerům (k jednomu use case jeden kontroler). Každý případ užití bude mít jednu nebo více akcí:
Vytvoříme tedy instanci Zend_Acl
. Přidání rolí je jednoduché a stejně tak přidání zdrojů :
$_acl = new Zend_Acl(); $_acl->add(new Zend_Acl_Resource('marks')); $_acl->add(new Zend_Acl_Resource('messages')); $_acl->add(new Zend_Acl_Resource('studentlist')); $_acl->add(new Zend_Acl_Resource('teacherlist')); $_acl->addRole(new Zend_Acl_Role('guest')); $_acl->addRole(new Zend_Acl_Role('student')); $_acl->addRole(new Zend_Acl_Role('parents'), 'student'); $_acl->addRole(new Zend_Acl_Role('teacher'), 'parents'); $_acl->addRole(new Zend_Acl_Role('admin'));Definovali jsme čtyři zdroje, v našem případě kontrolery a čtyři role v systému (navíc jsme ještě zavedli roli hosta pro případ, že uživatel není přihlášený, ale to není nezbytně nutné). Parametr v konstruktorech je identifikátor zdroje resp. role. První parametr funkce
addRole()
je instance třídy Zend_Acl_Role
, další parametry určují identifikátory rolí od nichž vytvářená role dědí práva. Tj. pokud není explicitně definováno pravidlo pro danou roli a zdroj, Zend prochází předky role a hledá, zda je nějaké pravidlo definováno pro předka role a zdroj. Pokud ano, je použito toto pravidlo. Předci role se prochází od posledního k prvnímu (tj. pokud bychom měli $_acl->addRole(new Zend_Acl_Role('teacher'), 'student','parents')
, hledají se prvně pravidla pro zdroj a roli parents
, až pokud opět žádné pravidlo není nalezeno, hledá se pravidlo pro zdroj a roli student
). Použije se pravidlo, které najde jako první - na pořadí, v jakém uvádíme předky role tedy záleží.
Definujme nyní tedy jednotlivá pravidla pro jednotlivé role a kontrolery:
$_acl->allow('student', 'marks','show'); $_acl->allow('parents', 'messages','show'); $_acl->allow('teacher', 'marks','add'); $_acl->allow('teacher', 'messages','add'); $_acl->allow('teacher', 'studentlist'); $_acl->allow('admin');Voláním metody
allow(role,zdroj,akce)
povolujeme roli s daným zdrojem provést uvedenou akci (shodou okolností je v našem případě akce akce na kontroleru, ale nemusí tomu tak být, zdroj i akce může být cokoli, nejen kontroler a akce na kontroleru). Pro zakázání bychom použili metodu deny()
. Pokud uvedeme jen roli a zdroj, pak se povolí všechny akce. Pokud ale uvedeme akci (jednu nebo více), ostatní, které nebyly uvedeny v seznamu jsou automaticky zakázané. V našem případě tedy např. student má právo na kontroleru marks
volat pouze akci show
, pokud bychom ale definovali právo následovně $_acl->allow('student', 'marks')
, měl by právo volat jak akci show
, tak akci add
. Pokud místo zdroje uvedeme null
, pak se dané pravidlo aplikuje na všechny zdroje, tj. opět např. pro roli student
by $_acl->allow('student', null,'show')
znamenalo, že student může volat akci show
nejen na kontroleru marks
, ale také např. na kontroleru messages
nebo jakémkoli jiném.U administrátora jsem nedefinovali žádný zdroj ani akci, což znamená, že má dovoleno vše.
Máme nyní tedy definované role a zdroje v systému a nastavena pravidla (patrně to všechno dáme do jedné třídy, např. MyAcl
). To vše ale zatím byly abstraktní věci, které nemuseli mít s realitou nic společného. Že zdroj bude kontroler a akce bude akce na kontroleru jsem měli jen v hlavě, framework o tom zatím nic neví. Musíme tedy implementovat třídu, kde frameworku řekneme, co je zdroj, co akce, kde má vzít roli uživatele a jak s tím vším naložit. Protože práva budeme kontrolovat pro každý požadavek, můžeme toto vše implementovat jako pulgin front controlleru.
class ZendTest_Acl_AclPlugin extends Zend_Controller_Plugin_Abstract{ private $_auth; private $_acl; private $_noacl = array('module' => 'default', 'controller' => 'aclerror', 'action' => 'index'); public function preDispatch(Zend_Controller_Request_Abstract $request) { $this->_auth = Zend_Auth::getInstance(); $this->_acl = ZendTest_Acl_MyAcl::getAcl(); if ($this->_auth->hasIdentity()) { $role = $this->_auth->getIdentity()->getUser()->role; } else { $role = 'guest'; } $controller = $request->controller; $action = $request->action; $module = $request->module; $resource = $controller; if ($this->_acl->has($resource)){ if (!$this->_acl->isAllowed($role, $resource, $action)) { $module = $this->_noacl['module']; $controller = $this->_noacl['controller']; $action = $this->_noacl['action']; } } $request->setModuleName($module); $request->setControllerName($controller); $request->setActionName($action); } }Ve výše uvedené části kódu prvně nastavíme na jaký kontroler má být přesměrován požadavek, pokud uživatel nemá právo provést požadovanou akci na příslušném kontroleru. V metodě
preDispatch()
získáme identitu uživatele a z ní jeho roli (roli máme připravenou již od minula) a dále definici pravidel. Z identity uživatele zjistíme jeho roli, pokud uživatel nemá identitu, tak zřejmě není přihlášen a je obsazen do role hosta. Dále z požadavku zjistíme kontroler a akci, kterou chce uživatel zavolat. Samotná kontrola práv proběhne na zavoláním $this->_acl->isAllowed($role, $resource, $action)
, kde jsem ještě před tím zjistili, zda je požadovaný zdroj v acl definován. Pokud zdroj není v acl definován, má k němu automaticky přístup kdokoli. Pokud je v acl definován, proběhne ověření, zda k němu má daná role přístup a pokud ne, provede se přesměrování na kontroler uvedený na začátku pluginu.
Toto je jen jednoduchý příklad, jak lze acl v Zendu použít. Plugin bychom pochopitelně mohli rozšířit např. tak, že pokud by uživatel nebyl přihlášený, tak by byl přesměrován na přihlašovací formulář a pod. Pokud by nám nestačil seznam povolených a zakázaných akcí, můžeme si implementovat vlastní třídu, která bude rozhodovat, zda je možno k danému zdroji přistupovat nebo ne. Ukázka je např. v manuálu Zendu, kde je to demonstrováno na přikladu, že chceme dovolit přistup jen z určitých IP adres.
Tiskni
Sdílej:
Prvni! =)
Predne diky za pekny clanek, chtel bych se zeptat, jak vypada implementace funkce ZendTest_Acl_MyAcl::getAcl();
zminena v kodu. Nejak to nemuzu najit=(