• No results found

2. REŠERŠE EXISTUJÍCÍCH MOBILNÍCH APLIKACÍ ... 20

N/A
N/A
Protected

Academic year: 2022

Share "2. REŠERŠE EXISTUJÍCÍCH MOBILNÍCH APLIKACÍ ... 20"

Copied!
52
0
0

Loading.... (view fulltext now)

Full text

(1)
(2)
(3)
(4)
(5)
(6)

Poděkování

Chtěl bych poděkovat svému vedoucímu bakalářské práce Ing. Igoru Kopetschkovi za pomoc a cenné rady při tvorbě tohoto projektu. Dále bych chtěl poděkovat společnosti MITEL s.r.o.

za poskytnutí serveru.

(7)

Abstrakt

Cílem této práce bylo vytvořit webové administrační rozhraní pro mobilní aplikaci WhatToDo in Liberec. Práce začíná rešerší existujících mobilních aplikací a návrhem řešení administračního systému. Dále práce obsahuje popis propagačního webu aplikace.

V hlavní části práce je podrobně popsáno administrační rozhraní. Popis začíná databází a její strukturou. Následuje podrobný popis všech možností a funkcí systému a jejich implementace.

V poslední části práce se píše o přípravě serveru, na kterém je umístěno administrační rozhraní a propagační web.

Systém byl vytvořen v jazyce PHP, JavaScriptu s využitím HTML5 a CSS3.

Klíčová slova:

administrační rozhraní, webová aplikace, PHP, JavaScript, Google Firebase

Abstract

The aim of this work was to create a web administration interface for mobile application WhatToDo in Liberec. The work begins with a search of existing mobile applications and a design of the administration system. The thesis also contains a description of the promotional website of the application.

The main part of the thesis describes the administration interface in detail. The description begins with the database and its structure. The following is a detailed description of all system options and functions and their implementation. In the last part of the thesis there is written about the preparation of the server where the interface and the promotional web are located.

The system was created in PHP, JavaScript using HTML5 and CSS3.

Keywords:

administration interface, web application, PHP, JavaScript, Google Firebase

(8)

1. ÚVOD ... 19

2. REŠERŠE EXISTUJÍCÍCH MOBILNÍCH APLIKACÍ ... 20

2.1.GOOGLE MAPS ... 20

2.2.MAPY.CZ ... 20

2.3.INCITY ... 20

3. NÁVRH APLIKACE ... 21

4. PROPAGAČNÍ WEB ... 22

5. ADMINISTRAČNÍ ROZHRANÍ ... 24

5.1.ÚČEL SYSTÉMU ... 24

5.2.DATABÁZE A ÚLOŽIŠTĚ ... 24

5.2.1. Instalace Cloud Firestore ... 24

5.2.2. Struktura databáze ... 25

5.2.2.1. Místa ... 26

5.2.2.2. Události ... 27

5.2.2.3. Místa ke schválení / Události ke schválení ... 27

5.2.2.4. Nabídky ... 28

5.2.2.5. Obrázky ke schválení ... 28

5.2.2.6. Uživatelé ... 28

5.3.MOŽNOSTI A STRUKTURA SYSTÉMU ... 28

(9)

14

5.3.2. Registrace a vstup do systému ... 29

5.3.3. Menu ... 30

5.3.4. Úvodní stránka - Místa ... 31

5.3.4.1. Detail místa ... 33

5.3.4.2. Přidání místa ... 34

5.3.4.3. Editace místa ... 36

5.3.5. Události ... 38

5.3.5.1. Detail události ... 39

5.3.5.2. Přidání události ... 39

5.3.5.3. Editace události ... 41

5.3.6. Místa ke schválení / Události ke schválení ... 42

5.3.7. Uživatelé ... 44

5.3.7.1. Detail uživatele ... 44

5.3.7.2. Přidání uživatele ... 45

5.3.7.3. Editace uživatele ... 45

5.4.FUNKCE PHP ... 46

5.4.1. add_image_to_storage($image) ... 46

5.4.2. check_rights($required) ... 47

5.4.3. user_reg($name, $pass, $email, $rights) ... 47

5.4.4. user_login($name, $pass) ... 47

5.4.5. check_user_exists($name) ... 48

(10)

5.4.6. get_db() ... 48

5.4.7. get_places($id_user = 0), get_events($id_user) ... 48

5.4.8. get_places_to_check(), get_events_to_check() ... 48

5.4.9. find_place($place_id) ... 48

5.4.10. find_place_to_check(), find_event(), find_event_to_check(), find_user(), find_offer() ... 48

5.4.11. get_location($id) ... 49

5.5.FUNKCE JAVASCRIPT ... 49

5.5.1. insert_place_select_type() ... 49

5.5.2. insert_event_select_type() ... 49

5.5.3. tableItemFilter() ... 49

5.5.4. preview_image(event) ... 50

5.5.5. initializeAutocomplete() ... 50

5.5.6. geocodeLatLng(), geocodeLatLngCard() ... 50

6. SERVER ... 51

6.1.APACHE HTTPSERVER ... 51

6.1.1. Instalace a konfigurace Apache ... 51

6.2.PHP ... 52

6.2.1. Instalace a konfigurace PHP ... 52

6.3.SSL ... 52

(11)

16

6.5.FTP SERVER ... 53

6.5.1. Instalace a konfigurace vsftpd ... 53

7. MOŽNÁ VYLEPŠENÍ ... 55

7.1.ODESÍLÁNÍ E-MAILŮ ... 55

7.2.RESPONZIVITA ... 55

7.3.SPRÁVA OBSAHU PROPAGAČNÍHO WEBU ... 55

8. ZÁVĚR ... 56

SEZNAM POUŽITÉ LITERATURY ... 57

(12)

Obrázek 1 - Propagační web ... 22

Obrázek 2 - Logo 2 ... 22

Obrázek 3 - Logo 1 ... 22

Obrázek 4 – Propagační web mobil 1 ... 23

Obrázek 5 – Propagační web mobil 2 ... 23

Obrázek 6 - Soubor s texty ... 29

Obrázek 7 - Registrační formulář ... 29

Obrázek 8 - Příhlašovací formulář ... 30

Obrázek 9 - Menu Admin ... 30

Obrázek 10 - Menu Manažer ... 30

Obrázek 11 - Menu Běžný uživatel ... 31

Obrázek 12 - Seznam míst ... 32

Obrázek 13 - Filtry ... 33

Obrázek 14 - Detail místa ... 34

Obrázek 15 - Přidání místa 1 ... 35

Obrázek 16 - Přidání místa 2 ... 35

Obrázek 17 - Místo přidáno ... 36

Obrázek 18 - Editace místa ... 37

(13)

18

Obrázek 21 - Nedostatečná práva ... 44 Obrázek 22 - Chyby ve formuláři ... 45

(14)

1. Úvod

Žijeme v době, kdy chytré telefony nahradily ty klasické a kdy už téměř každý člověk jeden vlastní. Samotný nárůst chytrých telefonů už možná není tak velký, ale stále se zvyšuje počet různých mobilních aplikací a lidí, kteří je využívají.

Jedním z cílů tohoto projektu bylo vytvořit mobilní aplikaci pro platformu Android, která usnadní turistům návštěvu Liberce a obyvatelům zvýší přehled o tom, co se v Liberci aktuálně děje. Účelem aplikace je dosáhnout toho, aby měl její uživatel vše, co potřebuje na jednom místě. To znamená za prvé, že turista nemusí chodit po městě s mapou a zbytečně těžkou knížkou a za druhé, nemusí vše hledat na internetu nebo mít stažených mnoho aplikací a v nich hledat.

Aplikace obsahuje seznam důležitých a zajímavých míst v Liberci rozdělených do kategorií s možností je filtrovat. Dále obsahuje seznam událostí, které se ve městě konají. To vše je možné také zobrazit na mapě.

Dalším cílem je, usnadnit přidávání dat do aplikace. Z tohoto důvodu bylo vytvořeno administrační rozhraní, ve kterém je možné přidávat nová místa a události. Aby se obyvatelé města Liberce, ale i ostatní uživatelé, mohli podílet na obsahu aplikace, může se do tohoto systému registrovat každý. Uživatel si bude moci zobrazit všechna místa a události, které přidal a upravovat je či mazat.

Z důvodu bezpečnosti je uživatele nezbytné rozdělit podle jejich práv. Vhodné je rozdělení na běžného uživatele a správce. Cílem je, mít v aplikaci pouze relevantní data. Proto musí mít správce možnost schvalování dat vkládaných do databáze.

Tento projekt je rozdělen na dvě části. Jedna část je samotná mobilní aplikace a druhá část je webový administrační systém, propagační web aplikace, server a databáze. Obsahem této bakalářská práce je druhá část projektu. Databáze byla navrhována společně s řešitelkou první části Michaelou Zámečníkovou, aby vyhovovala mobilní i webové aplikaci.

Celý projekt je vyvíjen pro firmu MITEL s.r.o.

(15)

20

2. Rešerše existujících mobilních aplikací

2.1. Google Maps

Aplikace Google Maps je zařazena mezi podobné aplikace, protože nabízí především služby jako je mapa, informace o místech na mapě a navigaci k těmto místům. Tyto služby jsou zde vytvořené velmi dobře, ale celá aplikace je tvořená pro celý svět, a tím někdy ztrácí intuitivnost.

Pro uživatele může být zdlouhavější najít souhrn potřebných informací o konkrétním městě.

2.2. Mapy.cz

Pro aplikaci Mapy.cz platí to samé jako v případě Google Maps. Je to sice česká aplikace, ale pořád nenabízí vše. Například seznam důležitých míst ve městě Liberci je pro uživatele složitě dostupný. Není jednoduché ho v aplikaci vyhledat.

2.3. InCity

Tato aplikace už je zaměřena konkrétněji než předchozí dvě. Je zaměřena na více českých měst včetně Liberce. Uživatel zde může vidět aktuální akce v Liberci a také body zájmu rozdělené do kategorií. Je zde také možnost podívat se na mapu, kde jsou místa označena špendlíky.

(16)

3. Návrh aplikace

Aplikace WhatToDo in Liberec byla navržena tak, aby byla přehledná a intuitivní. Každý uživatel by měl ihned zvládnout orientovat se v aplikaci a najít, co potřebuje. Dalším cílem bylo, aby aplikace obsahovala všechny informace o městu Liberec, které návštěvník může potřebovat. Tím pádem návštěvník nebude muset využívat více aplikací najednou nebo složitě hledat na internetu. V poslední řadě aplikace bude na míru města, takže kromě běžných informací a zajímavých míst, zde budou i taková, která znají například jen obyvatelé města.

Taková aplikace se ale neobejde bez možnosti spravovat její data. Byl tedy navržen systém, jehož účelem je tato správa. Mobilní aplikace obsahuje mimo jiné seznam míst a seznam událostí. Tyto položky je třeba do databáze přidávat a později třeba upravovat či mazat.

Možnost přidávat položky má každý registrovaný uživatel. Proto je nutné vést i správu uživatelů, včetně dělení do rolí podle práv. Správce systému musí mít přehled o přidaných místech a o historii změn. Sám tyto přidání a úpravy musí schvalovat, aby se v aplikaci neobjevovala nerelevantní či nevhodná data.

Kvůli ochraně osobních údajů se při registraci uživatele vyžaduje kromě hesla pouze přihlašovací jméno a e-mailová adresa.

(17)

22

4. Propagační web

Webové stránky aplikace WhatToDo in Liberec slouží k propagaci aplikace na internetu.

Návštěvník stránek se dozví základní informace o aplikaci a také co je v aplikaci nového. Dále je zde odkaz na Google Play, ke stažení aplikace do mobilního telefonu. V poslední řadě je na tomto webu v patičce odkaz na přihlášení do administračního systému.

Web je navržen jako jedna stránka, na které je vše viz Obrázek 1. Nahoře je logo aplikace, horizontální menu a výběr jazyka. Pod menu jsou pod sebou tři oddíly, které jsou každý přes celou šířku stránky. V prvním oddílu je na pozadí obrázek, krátké texty o aplikaci a obrázek mobilního telefonu. Zbývající dva oddíly jsou určeny informacím o aplikaci a novinkám.

Následuje už jen patička s odkazem na administrační rozhraní.

Logo je ve formátu GIF a po najetí myší se otočí a změní v název aplikace. Po kliknutí na položku menu se pohled uživatele posune na příslušný oddíl a položka je podtržena.

Obrázek 1 - Propagační web

Obrázek 3 - Logo 1 Obrázek 2 - Logo 2

(18)

Propagační web je responzivní viz Obrázek 4 a Obrázek 5. Při prohlížení na mobilním telefonu není zobrazen obrázek telefonu a není k dispozici menu. Jelikož je vše na jedné stránce, není třeba se zde pohybovat přes odkazy v menu. Výběr jazyka je přesunut do patičky.

Pro vývoj této stránky bylo využito převážně HTML a CSS. U interaktivního loga a položek v menu byl využit JavaScript. Při výběru jazyka je volán PHP skript, který naplní příslušnou session proměnnou, podle které se určí, který soubor s překlady se má příkazem include zahrnout.Aby byla stránka responzivní, byl přidat meta tag

<meta name="viewport" content="width=device-width, initial-scale=1”>

který zabrání prohlížeči simulovat telefonům větší rozlišení. Rozměry objektů jsou definovány procenty, takže je stránka flexibilní. Hlavní změny poté byly vyřešeny pomocí tzv. media queries @media screen and (max-width: 500px) { … }.

Styly stránky jsou díky tomu rozděleny podle jejich šířky.

Obrázek 5 – Propagační web mobil 1 Obrázek 4 – Propagační web mobil 2

(19)

24

5. Administrační rozhraní

5.1. Účel systému

Administrační rozhraní slouží ke správě dat aplikace WhatToDo. Tento systém je vytvořen pro to, aby správce nebo správci aplikace mohli jednoduše operovat s daty této aplikace. Dále bude sloužit i ostatním uživatelům kromě správců, a to například majiteli restaurace, který bude chtít mít svoji restauraci v systému a upravovat její data (název, otevírací doba, jídelní lístek atd.) nebo komukoliv jinému, kdo bude chtít přidat a případně i spravovat nějaký bod zájmu ve městě Liberec.

5.2. Databáze a úložiště

Pro databázi je využita technologie Google Firebase, konkrétně Cloud Firestore. Cloud Firestore je nová vylepšená verze jiné databáze Google, a to Realtime Database. Je to NoSQL cloudová databáze. Data se v ní ukládají jako dokumenty a dokumenty se sdružují v kolekcích.

V dokumentu je možnost uložit různé datové typy, například string, number, boolean, timestamp nebo pole.

5.2.1. Instalace Cloud Firestore

Pro využívání Cloud Firestore a celé Google Firebase je nutné mít účet Google. V konzoli Firebase je poté možné založit projekt. Projekt byl tedy založen pro účely mobilní i webové aplikace. V případě PHP se v první řadě musí v konzoli vytvořit soubor s údaji sloužícími k autentifikaci. Soubor se poté stáhne, umístí na disk serveru a cesta k němu uloží do proměnné prostředí GOOGLE_APPLICATION_CREDENTIALS. Poslední, co je třeba, je přidat do projektu knihovnu google/cloud-firestore. Aby tato knihovna fungovala, vyžaduje rozšíření gRPC.

Pro instalaci gRPC je třeba repozitář PHP rozšíření PECL, a nástroj Composer.

sudo apt-get install php7.0-dev php-pear phpunit

curl -sS https://getcomposer.org/installer | php

(20)

sudo mv composer.phar /usr/local/bin/composer

Pomocí PECL byla nainstalována samotná knihovna gRPC.

“sudo pecl install grpc”

Posledním krokem bylo přidání knihovny do projektu nástrojem Composer.

composer require “grpc/grpc:^v1.1.0”

Pokud je Composer správně nakonfigurovaný, přidá automaticky řádek “extension=grpc.so”

do souboru php.ini. Jinak je nutné ho tam přidat manuálně.

Pro lepší výkon knihovny gRPC je doporučeno nainstalovat a přidat rozšíření protobuf.

sudo pecl install protobuf

Po uvedeném příkazu je opět nutné přidat knihovnu do souboru php.ini.

5.2.2. Struktura databáze

V databázi je sedm kolekcí - místa, místa ke schválení, události, události ke schválení, nabídky, obrázky ke schválení a uživatelé. V každé kolekci jsou dokumenty reprezentující každý jedno místo, událost, nabídku nebo uživatele.

(21)

26

5.2.2.1. Místa

Každý dokument v kolekci má své unikátní ID a dále atributy uvedené v tabulce. Některé atributy se liší podle toho, o jaký typ místa se jedná. Povinné jsou type, name, location, rating a count_rating.

Název Typ Typ místa Význam

type string Všechny typ místa

id_user string Všechny ID uživatele

name string Všechny název

location geopoint Všechny poloha

description string Všechny popis

ListImage array Všechny pole obrázků

open array Všechny krom parkoviště otevírací doba entry string Všechny krom restaurací a barů vstupné

menu string Restaurace, bary jídelní/nápojový lístek

garden boolean Restaurace, bary zahrádka

playground boolean Restaurace dětský koutek

pets boolean Restaurace, bary, památky, kultura vstup se psy

rating number Všechny hodnocení

count_rating number Všechny počet hodnocení

(22)

5.2.2.2. Události

Dokument v kolekci událostí má také každý své ID. V této kolekci může mít každý dokument stejné atributy, které jsou vypsané v tabulce. Povinné jsou type, name, location, date, rating a count_rating.

Název Typ Význam

type string typ události

id_user string ID uživatele, který ji přidal

name string název

location geopoint poloha

date timestamp datum a čas konání

entry string vstupné

description string popis

bool1 boolean dabing/titulky, vnitřní/venkovní

bool2 string věková přístupnost

rating number hodnocení

count_rating number počet hodnocení

5.2.2.3. Místa ke schválení / Události ke schválení

Tyto dvě kolekce jsou podobné kolekcím míst a událostí. Je zde rozdíl pouze ve dvou atributech, které tu jsou navíc. První je hodnota typu timestamp, date_insert, tedy datum a čas, kdy uživatel místo nebo událost přidal. Druhý boolean checked, který

(23)

28

5.2.2.4. Nabídky

Dokumenty v této kolekci mají jen ID, název a obrázek. Nic víc není v aplikaci potřeba.

5.2.2.5. Obrázky ke schválení

Do této kolekce se uloží záznam, když uživatel mobilní aplikace přidá místu nebo události do galerie nový obrázek. Dokument s tímto záznamem obsahuje ID dokumentu a ID místa či události, ke které obrázek patří.

5.2.2.6. Uživatelé

V kolekci uživatelů jsou všichni uživatelé systému. Dokument reprezentující uživatele má unikátní ID, jméno, heslo (zašifrované), e-mail a práva. Kromě práv jsou všechny atributy typu string. Práva jsou typ number.

5.3. Možnosti a struktura systému

5.3.1. Přepínání jazyků

Administrační rozhraní i propagační web mají možnost přepínat jazyky. Na každé stránce je v pravém horním rohu výběr jazyka. Výchozí možnost je čeština a další jsou angličtina a němčina. Při výběru jedné z možností je zavolán PHP skript, který podle zvolené možnosti vloží do session proměnné zkratku vybraného jazyka. Každá stránka v systému hned na začátku příkazem include zahrne příslušný soubor s texty v daném jazyce. V souboru jsou konstanty obsahující text, který se bude zobrazovat uživateli. Náhled souboru na obrázku Obrázek 6.

(24)

5.3.2. Registrace a vstup do systému

Do systému je možné se registrovat i přihlásit z webové stránky aplikace WhatToDo, a to přes odkaz v patičce. Odkaz vede na přihlašovací stránku, odkud je možné přejít i k formuláři pro registraci viz Obrázek 7. Při registraci musí uživatel zadat platnou e-mailovou adresu, přihlašovací jméno a dvakrát heslo. Po odeslání registrace proběhne kontrola unikátnosti uživatelského jména a rovnosti hesel. Nově registrovanému uživateli je přiřazena role běžného uživatele s nejnižšími právy. Registrovat se může každý. Po registraci se může uživatel přihlásit do systému. Pro přihlášení do systému je vyžadováno uživatelské jméno a heslo.

Registrace je řešena HTML formulářem, který odesílá data metodou post ke zpracování k tomu určeným skriptem. Skript nejprve zkontroluje, zda jsou vyplněna všechna pole. Dále kontroluje rovnost zadaných hesel. V poslední kontrole zavolá funkci, která hledá v databázi uživatele podle jména a tím zjistí, jestli už uživatel se zadaným uživatelským jménem neexistuje.

Pokud vyplněné hodnoty projdou kontrolami, uživatelské heslo se zašifruje funkcí password_hash(). Jako uživatelská práva se automaticky vyplní ty nejnižší. Hodnoty se vloží jako parametry to funkce, která zajistí spojení s databází a vloží nový dokument.

Pokud je něco špatně, je naplněna příslušná session proměnná a uživatel je přesměrován zpět k formuláři. Zde na základě nastavené session je uživateli vypsána příslušná chyba a označené pole ve kterém se vyskytla.

Obrázek 6 - Soubor s texty

Obrázek 7 - Registrační formulář

(25)

30

je kontrolováno pomocí funkce password_verify() a řetězce v databázi u daného uživatele.

Pokud vyplněné hodnoty projdou kontrolami, nastaví se session proměnná obsahující identifikační číslo přihlášeného uživatele a další obsahující jeho práva. Uživatel je poté přesměrován na úvodní stránku systému.

Když nastane nějaká chyba, uživatel je přesměrován zpět k formuláři. Stejným způsobem jako při registraci se mu zobrazí příslušná chybová hláška a označí pole, kterého se chyba týká.

5.3.3. Menu

Menu obsahuje položky podle toho, jakou roli má právě přihlášený uživatel. Běžnému uživateli jsou určeny a zobrazeny položky “Místa” a “Události”. Dále je v menu možnost se odhlásit.

Správce s omezenými právy má menu rozšířené ještě o “Místa ke schválení”, “Události ke schválení” a “Nabídky”. Správce s nejvyššími právy má zobrazenou i položku “Uživatelé” pro správu všech ostatních uživatelů a jejich rolí.

Obrázek 9 - Menu Admin

Obrázek 10 - Menu Manažer Obrázek 8 – Příhlašovací formulář

(26)

Obrázek 11 - Menu Běžný uživatel

Menu má svůj vlastní soubor, který je pomocí příkazu include vložen na začátek každé stránky v administračním rozhraní. Kromě výše zmíněných položek menu obsahuje soubor také formulář pro výběr jazyka.

5.3.4. Úvodní stránka - Místa

Po přihlášení je uživatel přesměrován na stránku Místa, jejíž obsah se mění podle jeho práv.

V případě, že je správcem, zobrazí se tabulka všech míst v databázi aplikace viz Obrázek 12.

Běžnému uživateli se zobrazí jen jím přidaná místa.

V tabulce je ke každému místu zobrazen jeho název, který má zároveň v sobě odkaz na stránku detailu toho místa. Dále je zde typ místa (restaurace, památky, toalety a podobně), odkaz na stránku editace místa, a nakonec možnost místo smazat z databáze. Místa v tabulce je také možno filtrovat podle názvu a podle typu viz Obrázek 13. Na této stránce má uživatel také možnost přidat nové místo. Kliknutím na tlačítko Přidat se dostane na stránku přidání nového místa.

Nejprve se zavolají dvě funkce. První naváže spojení s databází Cloud Firestore a druhá načte všechna místa z kolekce míst a uloží do pole. Když se tvoří tabulka míst, tak se prochází cyklem for právě toto pole a pro každé místo se přidá tabulce jeden řádek.

(27)

32

Filtry nad tabulkou jsou řešeny JavaScriptem. První filtr filtruje místa podle jména. Je to tedy textové pole, které v atributu onkeyup volá filtrovací funkci. Funkce najde tabulku podle názvu třídy a v ní všechny řádky podle tagu a ke každému řádku také obsah prvního sloupce.

Nakonec prochází všechny řádky a obsah prvního sloupce porovnává s řetězcem vyplněným v textovém poli. V případě, že pole hledaný řetězec neobsahuje, nastaví se řádku v tabulce atribut display na hodnotu none.

Druhý filtr filtruje místa podle jejich typu. Je řešen stejnou funkcí jako filtr podle názvu. Ve funkci se jen řeší i obsah druhého sloupce. Vstupem filtru ale není tentokrát textové pole, ale výběr. Výběr je naplněný typy míst a při kliknutí na některé z nich se zavolá funkce.

Obrázek 12 - Seznam míst

(28)

5.3.4.1. Detail místa

Na stránce detail místa jsou uživateli zobrazena všechna data daného místa, která jsou v databázi. Například v případě restaurace je to název, typ, otevírací doba, jídelní lístek, poloha, obrázek a informace, zda má tato restaurace dětský koutek, zahrádku nebo povolený vstup se psem. Nad touto tabulkou jsou ještě dvě tlačítka, která umožnují uživateli místo smazat a editovat.

Na začátku se z parametru URL získá identifikační číslo místa, kterého detail se má zobrazit.

Následně se volá funkce, která na základě toho id najde v databázi v kolekci míst příslušné místo. Pokud ho tam nenajde, zavolá se druhá funkce, která ho najde v kolekci míst ke schválení.

První z tlačítek nad tabulkou slouží ke smazání místa. V URL adrese odkazu na skript, který vykonává smazání z databáze jsou dva parametry. Prvním parametrem je identifikační číslo a druhým je číslo kolekce. Skript, který místo maže musí vědět, jestli ho hledat a mazat v kolekci míst anebo míst ke schválení. Druhé tlačítko slouží k přesměrování uživatele k editaci místa. To má v odkazu jen jeden parametr a tím je identifikační číslo.

Následuje tabulka se všemi informacemi o místu. V každém řádku je vždy první sloupec, který obsahuje název atributu. Ve druhém nebo v dalších sloupcích jsou hodnoty. Některé atributy jsou specifické pro nějaké typy míst, a to je zde řešeno pomocí PHP podmínek. Díky nim jsou

Obrázek 13 - Filtry

(29)

34

5.3.4.2. Přidání místa

Po vstupu na stránku pro přidání místa vidí uživatel možnost vybrat typ místa ve formě kombinovaného pole. Po zvolení typu místa se objeví zbytek tabulky, tedy objeví se ty řádky s atributy příslušnými zvolenému místu. Povinné atributy (název, poloha) jsou označeny hvězdičkou a uživateli nebude povoleno přidat místo bez jejich vyplnění. Zároveň není povoleno přidat místo s již existujícím názvem v databázi nebo s neplatnými souřadnicemi.

V případě, že uživatel zapomene vyplnit název, vyplní již existující nebo zapomene na polohu či vyplní neplatné souřadnice, bude vrácen zpět k formuláři, kde budou zvýrazněna špatně vyplněná pole a vedle vypsáno co bylo špatně. Všechny ostatní atributy, které zvolil či vyplnil jsou zapamatované a předvyplněné, aby uživatel nemusel vyplňovat celý formulář znovu.

Většina atributů je ve formě textového vstupu. Volba otevírací doby je tvořena několika kombinovanými poli s možnostmi vybrat hodinu a minutu. Dále je možnost zaškrtnout, že je otevřeno nonstop nebo naopak zavřeno. Polohu místa má uživatel možnost přidat kromě souřadnicemi také zadáním adresy. K tomu je využito Google Places API.

Obrázek 14 - Detail místa

(30)

Po správném vyplnění a odeslání formuláře běžný uživatel dostane informaci, že jeho nové místo čeká na schválení správcem a je přesměrován na seznam jeho míst. Pokud místo přidá správce, je přesměrován rovnou na místa ke schválení.

Na začátku se plní proměnné pro jednotlivé pole formuláře. Když session proměnná příslušná svému poli něco obsahuje, naplní se lokální proměnná, která se pak zobrazí jako výchozí hodnota ve formuláři. Pokud nic neobsahuje, lokální proměnná bude prázdná.

Následuje vykreslení formuláře. Formulář je vytvořen jako tabulka. Tabulce se zobrazují řádky podle toho, o jaký typ se jedná.

To je řešeno pomocí CSS a JavaScriptu. Řádky tabulky mají každý své ID a přes něj je v souboru se styly nastaven atribut display na hodnotu none. Při výběru typu místa se spustí JavaScriptová funkce, ve které se na základě vybraného typu nastaví správným řádkům

Obrázek 15 - Přidání místa 1

Obrázek 16 - Přidání místa 2

(31)

36

Skript nejprve zkontroluje, zda jsou vyplněna všechna povinná pole, v tomto případě název a poloha. U polohy také kontroluje, jestli zadaná zeměpisná šířka a délka jsou čísla a v požadovaném intervalu. V případě že se vyskytne jedna nebo více chyb, naplní se ke každé chybě session proměnná, aby na chybu mohl reagovat formulář.

Po kontrolách začne samotné odesílání dat do databáze. První se řeší obrázek. Ten se ukládá do Firebase Storage a do databáze se ukládá jeho URL adresa. Ve skriptu se volá funkce, která převezme obrázek jako parametr, upraví jeho velikost, uloží do úložiště a vrátí URL. Pokud z formuláře žádný nepřijde, do databáze se uloží prázdný řetězec. Ze souřadnic polohy místa se vytvoří objekt typu GeoPoint a z aktuálního času Timestamp. Když jsou všechna data připravena, blokem switch se podle typu přidávaného místa naplní asociativní pole správnými klíči a hodnotami. Nakonec se zavolá funkce, která vytvoří spojení s databází a následně v ní vytvoří nový dokument s daty z pole. Po úspěšném vložení do databáze je uživatel přesměrován pomocí funkce header podle toho, jaká práva jsou uložena v session proměnné. V opačném případě je přesměrován zpět k formuláři, což je zajištěno využitím proměnné $_SERVER[‘HTTP_REFERER’], ve které je uložena předchozí URL adresa.

5.3.4.3. Editace místa

Stránka editace místa je hodně podobná stránce pro přidání místa. Rozdíl je v tom, že uživatel už nemá možnost zvolit si typ místa, protože ten už je předem zvolený a podle něho už je zobrazen zbytek formuláře. Ve formuláři jsou předem vyplněny data editovaného místa, která má v databázi. Po odeslání formuláře probíhají stejné kontroly jako při přidávání místa. Pokud nastane nějaká chyba, uživatel je opět odkázán zpět k formuláři, kde je označeno a popsáno co nevyplnil správně. To, co předtím vyplnil do jiných polí je zapamatováno a předem vyplněno

Obrázek 17 - Místo přidáno

(32)

a tam kde nic nevyplnil je zase to, co bylo v databázi. Když vše proběhne správně, místo je přidáno k místům ke schválení.

Tabulka na stránce editace místa je řešena podobně jako na stránce pro přidání. Řádky nejsou zobrazovány a skrývány pomocí JavaScriptu, ale pomocí PHP. Není totiž nutné nic měnit bez toho, aniž by se načítala celá stránka jako při výběru typu místa. Další změna je hned na začátku, kde se plní lokální proměnné následně zobrazené v tabulce jako výchozí hodnoty.

Tentokrát se při neexistenci session proměnné ze skriptu vykonávajícího editaci místa nezapisuje prázdný řetězec, ale hodnota, která je u místa uložena v databázi. V případě polohy místa se z databáze načtou souřadnice a využitím Google Places API se z nich vytvoří adresa a vyplní do pole určeného pro ni.

Na začátku se nejen pro tento účel musí získat identifikační číslo upravovaného místa. To přichází jako parametr v URL adrese a je tedy získáno z pole $_GET. Potom se zavolá funkce, která najde v databázi v kolekci míst místo s tímto identifikačním číslem. Pokud ho nenajde, zavolá se další funkce, která místo hledá v kolekci míst ke schválení. Obě funkce vrací objekt

Obrázek 18 – Editace místa

(33)

38

Ve formuláři je kromě textových polí a výběrů také pár skrytých polí. Ve skriptu, který formulář zpracovává, se tyto hodnoty využijí.

Jedna z toho je typ místa. Ten se využije už při kontrolách, protože například otevírací doba se netýká místa typu parkoviště, takže se nijak nezpracovává. Poté se typ využije při sestavování pole dat pro vložení místa do databáze, kde pro každý typ můžou být jiné hodnoty.

Další skrytou hodnotou je identifikační číslo místa, které se v případě editace uloží spolu s ostatními atributy do databáze, protože bude později potřeba. Další dvě hodnoty jsou hodnocení a počet hodnocení. To jsou čísla, které má každé místo, ale uživatel je zde nemá možnost nijak měnit. Mění se jen přímo z mobilní aplikace a zde se jen musí zachovat.

Poslední hodnota, která se posílá, je URL adresa obrázku. Pole pro zadávání souboru s obrázkem není na rozdíl od ostatních předvyplněné, pokud by tedy uživatel nechtěl obrázek měnit, jeho hodnota by byla ve skriptu prázdná. V tom případě se použije ta ze skrytého pole.

5.3.5. Události

Na stránce událostí je podobný seznam jako seznam míst. Správce vidí všechny události v databázi a běžný uživatel jen ty, které přidal on. Každá událost má v tabulce své jméno, typ a možnosti editovat či smazat. Uživatel má možnost vyhledávat podle názvu a filtrovat podle typu. Vedle filtrů je tlačítko, které umožňuje přidat novou událost.

Na začátku se zavolají dvě funkce, které se připojí k databázi a vrátí všechny události z hlavní kolekce událostí. Než se začne zobrazovat tabulka s událostmi, jsou na řadě filtry. Ty jsou dva, jeden filtruje podle názvu a jeden podle typu události. První je ve formě textového pole reaguje na každý napsaný nebo smazaný znak tím, že volá filtrovací funkci v atributu onkeyup.

Druhý je ve formě výběru, který je naplněný všemi možnými typy události a volá funkci při kliknutí na některou volbu. Oba dva filtry volají tu jednu stejnou funkci, která se využívá i u filtru míst a uživatelů. Tlačítko pro přidání události vedle filtru je klasický prvek

<button>, který je zabalený v odkazu na stránku pro přidání místa.

Pod filtry a tlačítkem je hlavní část stránky, tedy tabulka s událostmi. Tabulka je zobrazena staticky, stejně tak její hlavička s názvy sloupců, ale řádky po jednom cyklem for, který prochází pole událostí načtených z databáze.

(34)

5.3.5.1. Detail události

V detailu události se zobrazí uživateli všechny informace, které má událost v databázi. Dále jde zde možnost přejít k editaci této události nebo ji smazat z databáze.

Ze stránky, ze které se přijde na detail události přijde jako parametr URL adresy identifikační číslo události. To se hned na začátku získá z pole $_GET a pošle jako parametr do funkce, která podle něj najde událost v databázi v kolekci událostí. Pokud ho tam nenajde, znamená to, že se zobrazuje detail události, která zatím čeká na chválení a zavolá se druhá funkce, která ho najde v kolekci událostí ke schválení.

Dvě tlačítka nad tabulkou odkazují, jedno na smazání a jedno na editaci místa. To první, tedy smazání události, posílá dva parametry URL. První parametr je identifikační číslo události a druhý je číslo kolekce. Druhé tlačítko odesílá jen identifikační číslo.

Samotná tabulka má dynamický obsah, a je řešena pomocí PHP. Řádky, které se netýkají všech typů míst jsou obaleny PHP podmínkami a zobrazeny jen tehdy, když se jedná a místo, které má tyto atributy.

5.3.5.2. Přidání události

U přidání události musí uživatel stejně jako při přidávání místa nejprve zvolit typ události (koncert, kino, výstava atd.). Poté se zobrazí zbytek tabulky s příslušnými atributy jako jsou například název, poloha, datum a čas, či informace, zda je událost vhodná pro děti. Polohu je možné zadat souřadnicemi nebo adresou. Oproti místům je zde navíc datum a čas, který uživatel zadává pomocí malého kalendáře.

Po odeslání formuláře probíhají kontroly povinných atributů a případně jejich správnost. Když je vše v pořádku, událost je odeslána ke schválení správci a běžný uživatel je o tom obeznámen.

Správce je přesměrován na stránku událostí ke schválení, kde nově přidanou událost může schválit, a tím zapsat mezi události, které zobrazuje mobilní aplikace.

Ještě před zobrazováním HTML se ukládá obsah session proměnných, pokud existují, do

(35)

40

Podoba tabulky závisí na typu přidávané události. Pomocí CSS a atributu display se skryjí všechny řádky tabulky kromě jednoho, ve kterém je typ události, přesněji výběr typu. Při kliknutí na některou z možností se zavolá JavaScriptová funkce, která na základě typu nastaví těm správným řádkům atribut display na hodnotu table-row. Tato funkce se volá ihned při načtení stránky. Pokud není vybraný žádný typ, tak se nic neděje, ale pokud je ve formuláři nějaká chyba a procesní skript uživatele vrátí zpět, tak je typ předem vybraný a řádky se zobrazí. Když je chyba, tak je také naplněna jedna nebo více session proměnných příslušných této chybě. Pod každým řádkem, kde je povinné pole nebo může nastat jiná chyba, je ještě řádek, který je obalený PHP podmínkou kontrolující obsah session proměnné s chybou. V případě, že tedy chyba nastala, se zobrazí chybová hláška a pole se zvýrazní.

Formulář využívá metodu post.

Ve skriptu, který formulář zpracovává, se nejprve uloží obsah všech polí z pole $_POST.

Následně proběhnou kontroly, jestli jsou vyplněna všechna povinná pole a správně vyplněna ta ostatní. Když je něco v nepořádku, naplní se session proměnná podle toho, jaká nastala chyba a po kontrolách se uloží všechny správně vyplněné údaje taktéž do session a uživatel je přesměrován zpět k formuláři.

Když kontroly nenajdou žádnou chybu, z vyplněného času události a z aktuálního času se udělají objekty typu Timestamp a ze souřadnic polohy objekt typu GeoPoint. Když je vyplněný obrázek, tak se zavolá funkce, která ho uloží do úložiště Firebase storage a vrátí jeho URL. Pokud není vyplněný tak se uloží jako prázdný řetězec. Následně se podle typu události vytvoří pole s klíči a hodnotami jako má událost v databázi a událost se uloží do kolekce událostí ke schválení. Nakonec je uživatel přesměrován zpět na stránku událostí.

(36)

5.3.5.3. Editace události

Editace události opět probíhá podobně jako její přidávání s tím rozdílem, že ve formuláři jsou předem vyplněná data editované události z databáze.

Kód stránky pro editaci se od přidání liší hned na začátku, kde se z parametrů URL získává identifikační číslo události. Nalezení události v databázi obstarává jedna ze dvou funkcí. První hledá v hlavní kolekci událostí a pokud nenajde, tak druhá hledá v kolekci událostí ke schválení. Funkce vrátí objekt typu DocumentSnapshot, se kterým se dále pracuje jako s asociativním polem. Při plnění lokálních proměnných, které se zobrazují jako výchozí hodnoty formuláře, se vždy při existenci session proměnné použije její hodnota a při neexistenci právě hodnota z pole získaného z databáze.

Řádky tabulky se tentokrát nezobrazují a neskrývají pomocí JavaScriptu, ale obstarává to PHP.

Tabulka po načtení stránky má už jasně danou podobu podle typu místa, které je editováno a není potřeba nic měnit.

Obrázek 19 - Výběr - datum a čas

(37)

42

atributy má mít pole odesílané do databáze. Druhou hodnotou je identifikační číslo události, která má být upravena. To se přidá ke každé události, která se ukládá do kolekce událostí ke schválení, a využívá se to až při samotném schvalování.

Předtím než dojde k odesílání do databáze, proběhnou ještě kontroly stejné jako při přidávání místa. Odesílání do databáze je podmíněno úspěšným výsledkem těchto kontrol.

5.3.6. Místa ke schválení / Události ke schválení

Tyto dvě stránky jsou v menu zobrazeny pouze správci a ten jediný tam má přístup. Slouží k tomu, aby mohl správce dokončit proces přidání místa či události.

Vzhled a rozložení stránek je stejný jako u vlastních stránek míst a událostí. Navíc je tam pouze čas přidání na seznam schválení a stav schválení. K možnostem editovat a smazat je navíc možnost schválit. Seznam položek je řazený podle stavu a poté podle data přidání na seznam.

Správce se zde může podívat na nově přidané či nově upravené položky a zkontrolovat, zda všechny údaje jsou opravdu validní a neobsahují nesmyslný či nevhodný obsah. Podle toho se rozhodne, jestli místo smaže, nebo schválí. Po schválení se položka přidá mezi ostatní zobrazované v aplikaci nebo v případě editace se jen editují data již existující položky. Nakonec se jen v seznamu ke schválení změní stav.

Předtím než se začne řešit obsah stránky, zavolá se funkce, která zkontroluje, jaká práva má přihlášený uživatel. Pokud má práva obyčejného uživatele, pak je přesměrován na hlavní stránku a je mu zobrazena hláška informující o nedostatečných právech. Funkci se jako parametr předává hodnota práv manažera, tedy „2“. To jsou minimální práva, která musí uživatel mít pro tuto stránku.

Obrázek 20 - Seznam míst ke schválení

(38)

Místa nebo události, dále jen položky, se na začátku funkcí načtou z databáze a uloží do pole.

Každá položka má na svém řádku v tabulce kromě jména a typu také datum a čas přidání na seznam. Ten se do databáze přidává při každém přidání nebo editaci položky. Dalším sloupcem, který je tam navíc je stav položky. Ten ukazuje, jestli už byla položka správcem schválena nebo ne. Podle těchto dvou sloupců je seznam seřazen. Nejprve se řadí právě podle stavu, aby nahoře byly položky, které čekají na schválení a poté podle data a času přidání na seznam, aby byly výš položky, které čekají déle. O řazení se stará funkce, která načítá položky z databáze. Pole už je tedy předem seřazené.

Pole v tabulce ve sloupci se stavem jsou od sebe barevně odlišena, tedy schválené položky mají zelené pozadí a neschválené mají červené. Toto barevné rozdělen je řešeno ve filtrovací funkci, která se volá i při každém načtení stránky. Ve funkci se prochází všechny řádky a podle obsahu buňky s obsahem se nastaví správná barva pozadí.

Ve sloupcích s hlavičkou „Akce“ jsou tři odkazy. První odkáže správce na stránku pro editaci položky a v parametru URL pošle její identifikační číslo. Druhý položku smaže. Odkáže tedy na skript, kterému jako parametry URL odešle identifikační číslo a číslo kolekce, ze které má mazat. Poslední odkaz spouští skript, který položku schvaluje.

Skript se nejdříve spojí s databází. Poté podle identifikačního čísla položky získaného z parametru URL najde v kolekci položek ke schválení dokument a nastaví mu atribut checked na hodnotu true. Vložení do hlavní kolekce položek se liší podle toho, jestli jde o položku editovanou nebo nově přidanou. To skript zjistí podle toho, jestli má dokument atribut place_edit_id, který se nastavuje jen položkám při editaci.

V případě, že jde o nově přidaný dokument, uloží se pole se všemi jeho daty z kolekce položek ke schválení. Následně se z tohoto pole odstraní stav a datum přidání na seznam ke schválení.

Nakonec se v hlavní kolekci položek vytvoří nový dokument a nastaví se mu data z pole.

Uživatel je přesměrován zpět k položkám ke schválení.

Ve druhém případě se opět uloží všechna data dokumentu do pole. Dále se do proměnné uloží identifikační číslo položky, které se u ní drží od chvíle, kdy se začala editovat. Následně se

(39)

44

dokument a jeho data se přepíší na ta nová. Uživatel je nakonec přesměrován zpátky na seznam položek ke schválení kde položka, kterou schválil, bude označena za schválenou.

5.3.7. Uživatelé

Stránku uživatelé vidí a má do ní přístup pouze správce s nejvyššími právy. Slouží ke správě existujících uživatelů i přidávání nových.

Jednotliví uživatelé jsou zobrazeni v tabulce. U každého je jméno, role a email. V posledním sloupci je odkaz na editaci. Nad tabulkou je tlačítko pro přidání nového uživatele. Uživatele je možno také filtrovat podle jména a podle role.

Tak jako u míst a událostí ke schválení, i zde nejdříve proběhne kontrola práv. Zavolá se funkce, které se předají jako parametr požadovaná práva, tedy hodnota „1“. Jako místa a události jsou uživatelé také v databázi Cloud Firestore. Na začátku funguje tedy vše podobně jako u ostatních stránek se seznamy. Filtry jsou řešeny stejnou funkcí v JavaScriptu jako u ostatních. Údaje o uživatelích se zobrazují pomocí cyklu for, který prochází pole uživatelů načtených z databáze. Jméno a e-mail jsou vypisovány přímo, ale role je vypisována příkazem switch. Ten vypisuje roli podle toho, jaké číslo práv ve formě čísla přijdou z databáze.

5.3.7.1. Detail uživatele

Do detailu uživatele se správce dostane kliknutím na jméno v seznamu uživatelů. Může zde vidět všechny informace o uživateli, které jsou v databázi. Také zde může uživatele smazat nebo přejít do editace.

I v detailu uživatele se kontrolují práva přihlášeného uživatele. Funkce se volá ale jen tehdy, pokud se nejedná o detail uživatele, který je zrovna přihlášený. Porovnají se tedy ID v parametru URL adresy a ID v session proměnné. Pokud má uživatel nedostatečná práva

Obrázek 21 - Nedostatečná práva

(40)

a nejedná se o detail jeho účtu, je přesměrován na hlavní stránku a vidí hlášku o nedostatečných právech.

5.3.7.2. Přidání uživatele

Pro přidání uživatele slouží jednoduchý formulář s atributy jméno, email, heslo, heslo znovu a role. Po přidání proběhne kontrola povinných polí, což jsou všechny, kontrola unikátnosti jména a také kontrola rovnosti zadaných hesel. Pokud nastane nějaká chyba, je správce přesměrován zpátky k formuláři. Když je vše v pořádku, nový uživatel je přidán do databáze uživatelů na serveru.

Formulář odešle data metodou post ke zpracování příslušným skriptem. Skript kontroluje, jestli jsou všechna pole vyplněná, hesla stejná a jestli uživatelské jméno už v databázi není.

Pokud je něco z toho v nepořádku, naplní se session proměnné příslušné těmto problémům.

Dále se naplní další session proměnné daty z formuláře. Správce je následně přesměrován zpět k formuláři, kde se díky session proměnným zobrazí, co vyplnil špatně a také se předem vyplní pole, která vyplnil správně, aby už je nemusel vyplňovat znovu.

Když kontroly nezaznamenají žádnou chybu, zašifruje se uživatelské heslo funkcí password_hash() a následuje vložení nového záznamu do databáze uživatelů. Správce je nakonec přesměrován na seznam uživatelů.

5.3.7.3. Editace uživatele

Obrázek 22 - Chyby ve formuláři

(41)

46

Na této stránce také nejprve proběhne kontrola práv. Může se sem dostat správce s nejvyššími právy a zároveň majitel účtu, který se má editovat. V ostatních případech je uživatel přesměrován na hlavní stránku.

Formulář se trochu liší právě podle toho, jestli ho vyplňuje správce, nebo uživatel upravující svůj profil. Správce má zde navíc možnost měnit práva/roli upravovaného uživatele pomocí výběru ze třech možností. Běžný uživatel tuto možnost samozřejmě nemá.

Skript, který zpracovává data z formuláře pro editaci uživatele provádí stejné kontroly vyplněných údajů jako ten, který zpracovává data z formuláře pro přidání uživatele. Kontroly se liší jen v případě hesla. Nejdřív se kontroluje, jestli se hesla shodují, ať jsou vyplněná nebo ne. Pokud se neshodují, zaznamená se chyba. Když se shodují a jsou vyplněná, heslo se zašifruje a do databáze pošle změněné. Když nejsou vyplněná, zůstane heslo nezměněné.

Nakonec se skript spojí s databází a upraví dokument, který najde pomocí identifikačního čísla upravovaného uživatele, které dostane v adrese URL a získá jí v proměnné $_GET.

5.4. Funkce PHP

V administračním rozhraní se využívá mnoho funkcí. Většina z nich je v PHP souboru určeném právě jen pro funkce. Tento soubor je příkazem require zahrnut téměř ve všech ostatních souborech systému.

Na začátku souboru se příkazem use importují třídy potřebné pro některé funkce. Jsou to například třídy potřebné pro práci s Cloud Firestore, Cloud Storage nebo Firebase.

Ještě před samotnými funkcemi se kvůli připojování k databázím ukládají do konstant přístupové údaje.

5.4.1. add_image_to_storage($image)

Tato funkce ukládá obrázek do úložiště Firebase storage. Ještě před tím, než se obrázek ukládá, se upravují jeho rozměry. Rozměry původního obrázku jsou získány PHP funkcí getimagesize(). Pokud je jeden z jeho rozměrů větší než dané maximum, zmenší se na toto maximum. Poměr stran musí zůstat stejný, takže když šířka obrázku přesahuje povolené

(42)

maximum, nastaví se na maximum a výška na maximum podělené podílem původní šířky a výšky.

Jakmile je obrázek připravený, připojí se funkce k úložišti Firebase Storage. Využije k tomu Kreait, sadu nástrojů pro práci s Firebase. Nejdřív se vytvoří instance třídy ServiceAccount, kdy se jako parametr konstruktoru vloží cesta k autentifikačnímu souboru vygenerovanému v konzoli Google Firebase. Ta je vyžadována při vytváření objektu Firebase/Factory. Z tohoto se přes objekt Storage vytvoří objekt souboru, tedy v tomto případě obrázku. Následně se přes FilesystemInterface vloží objekt do úložiště. Pokud už tam je soubor se stejným názvem, přidá se k názvu řetězec náhodných znaků. Nakonec se pro soubor vytvoří veřejná URL, kterou funkce vrátí. V případě neúspěchu vrátí 0.

5.4.2. check_rights($required)

Funkce v parametru převezme požadovaná práva a porovná je s právy aktuálně přihlášeného uživatele. Pokud jsou práva nedostačující, uživatel je ihned přesměrován na úvodní stránku systému.

5.4.3. user_reg($name, $pass, $email, $rights)

Tato funkce je využitá při registraci uživatele a při přidávání uživatele správcem. Nejprve vytvoří instanci třídy FirestoreClient. Následně uloží do pole parametry s údaji o uživateli. Nakonec v kolekci uživatelů vytvoří nový dokument, kterému nastaví data z pole.

5.4.4. user_login($name, $pass)

Funkce user_login() převezme uživatelské jméno a heslo jako parametry. Vytvoří FirestoreClient a v kolekci uživatelů hledá pomocí metody where uživatele se jménem z parametru. Pokud ho nenajde, naplní session proměnnou příslušnou této chybě a vrátí hodnotu false. Když ho najde, funkcí password_verify() ověří správnost hesla.

V případě, že je heslo nesprávné, naplní session proměnnou a vrátí false. V opačném případě naplní session proměnné pro ID přihlášeného uživatele a pro jeho práva a vrátí

(43)

48

5.4.5. check_user_exists($name)

Ve funkci se vytvoří instance třídy FirestoreClient. Pomocí metod where a documents se hledá v kolekci uživatelů uživatel se jménem v parametru funkce. Podle výsledku funkce vrací true nebo false.

5.4.6. get_db()

Tato funkce vytvoří a vrátí instanci třídy FirestoreClient. Potřebuje k tomu identifikační číslo projektu v konzoli Google Firebase.

5.4.7. get_places($id_user = 0), get_events($id_user)

Funkce nejprve vytvoří instanci třídy FirestoreClient. Ta má metodu collection, která s parametrem název kolekce vrátí odkaz na kolekci položek (místa, události). Z něj se metodou documents získá pole položek typu DocumentSnapshot, které funkce vrátí.

U posledního kroku záleží na parametru funkce, tedy ID uživatele. V případě, že je funkce volaná bez parametru, metoda documents vrátí všechny položky. Ve druhém případě se pomocí metody where najdou jen ty položky, které mají v atributu id_user hledané ID.

5.4.8. get_places_to_check(), get_events_to_check()

Tyto funkce fungují stejně jako funkce get_places() a get_events() jen s těmi rozdíly, že při vytváření odkazu na kolekci dávají jako parametr jiný název kolekce a nevstupuje do ní žádný parametr, protože nezáleží na ID uživatele.

5.4.9. find_place($place_id)

Na začátku funkce vytvoří instanci třídy FirestoreClient. Přes název kolekce a identifikační číslo hledaného dokumentu získá funkce objekt DocumentSnapshot a vrátí ho. Pokud dokument s tímto id neexistuje, vrátí false.

5.4.10. find_place_to_check(), find_event(), find_event_to_check(), find_user(), find_offer()

Tyto funkce dělají to samé jako funkce find_place($place_id), jen hledají místo, událost, nabídku nebo uživatele v jiné kolekci.

(44)

5.4.11. get_location($id)

Funkce vytvoří instanci třídy FirestoreClient, najde dokument podle názvu kolekce a podle identifikačního čísla a metodou getGeoPoint() získá jeho polohu a tu vrátí.

5.5. Funkce JavaScript

5.5.1. insert_place_select_type()

Tato funkce se volá na stránce přidávání míst. Uživateli je tam zobrazen jen jeden řádek tabulky, kde je výběr z typů míst. Funkce má poté za úkol ukázat uživateli ty řádky, které přísluší vybranému typu místa. Funkce se volá hned po načtení stránky a také po kliknutí na vybraný typ.

Na začátku se vytvoří pole. Do toho pole se postupně uloží všechny řádky tabulky nalezené podle jejich ID. Když je pole naplněné, tak se celé projde cyklem for a nastaví se všem řádkům atribut CSS display na hodnotu none. Další události už jsou podmíněné výběrem typu, takže neproběhnou, pokud je funkce zavolaná načtením stránky.

Pokud je typ vybrán, je všem řádkům s atributy týkajícími se všech míst nastavena hodnota CSS vlastnosti display na table-row. Další změny už jsou závislé na konkrétním typu a podle toho jsou podmíněny.

5.5.2. insert_event_select_type()

Tato funkce je téměř identická funkci insert_place_select_type(). Rozdíly jsou jen v ID řádků a typech, protože ty se u událostí a míst liší.

5.5.3. tableItemFilter()

Funkce starající se o filtrování seznamů míst, událostí a uživatelů. Volá se celkově tedy na pěti stránkách. V této jedné funkci se řeší filtr podle jména i filtr podle typu. Dále se funkce stará

(45)

50

Nejprve se podle ID najdou prvky v HTML. Jsou to textový vstup pro zadání jména a výběr pro výběr typu. Hodnoty obou prvků jsou převedeny na velká písmena a uloženy. Podle názvu třídy je nalezena tabulka, v ní podle tagu nalezeny řádky a uloženy do pole. Nakonec jsou ještě podle názvu třídy nalezeny a do pole uloženy buňky se stavem položky ke schválení. Následují dva cykly for.

První je cyklus, který filtruje. Prochází pole řádků a pro každý řádek provádí kontrolu. Kontrola spočívá v tom, že porovnává obsah sloupce s názvem s řetězcem, který byl uložen na začátku funkce, a to samé dělá i s typem. Tím funguje i filtrování podle obou kritérií zároveň. Když řádek splňuje podmínku, vrací se hodnota CSS vlastnosti display na výchozí a když ne, tak se nastaví na none.

Druhý cyklus prochází pole buněk se stavem položky ke schválení. Vždy zkontroluje obsah buňky a podle toho nastaví barvu pozadí.

5.5.4. preview_image(event)

Funkce, která zajišťuje, aby uživatel viděl obrázek, který nahrál při vkládání nebo editování místa nebo události. Volá se, když je ve vstupním poli typu file přidán soubor.

Nejprve se vytvoří instance třídy FileReader. Té se nastaví chování, že když se načte soubor, vyhledá podle ID prvek <img>, kterému dá do atributu src ten soubor.

5.5.5. initializeAutocomplete()

Tato funkce vytvoří instanci třidy Autocomplete z Google Places API a přiřadí k ní příslušný textový vstup. Z nalezené adresy získá zeměpisnou šířku a délku a vyplní do jejich textových polí.

5.5.6. geocodeLatLng(), geocodeLatLngCard()

Tyto funkce využívají Google Maps API a třídu Geocoder. Najdou si textové vstupy nebo pole v tabulce, kde jsou souřadnice. Podle těchto souřadnic najdou objekt, ze kterého vrátí příslušnou adresu.

(46)

6. Server

Firmou byl poskytnut virtuální stroj (2vCPU, 8GB RAM, 60GB HDD on SAS), na kterém je operační systém Ubuntu Server 18.04.2 LTS. Tento stroj je na virtualizační platformě VMware: VMWARE-HPE-ESXi-6.0.0-Update3-iso-600.10.1.3.5, která běží na fyzickém serveru od společnosti HP ProLiant DL580 G7.

6.1. Apache HTTP Server

Apache je webový server, který je dlouhodobě nejpoužívanějším webovým serverem na celém světě. Poskytuje široké spektrum funkcí, jako je například podpora řady programovacích jazyků nebo SSL či TLS.

Co se týče výkonu, tak Apache není sice tak výkonný jako například webový server Nginx pro statický obsah, ale u dynamického je to srovnatelné.

6.1.1. Instalace a konfigurace Apache

Jako webový server byl zvolen Apache HTTP Server. Důvodem bylo částečně to, že je to aktuálně nejčastěji používaný webový server, z čehož vyplývá jeho spolehlivost. Dále nabízí spoustu funkcí a v neposlední řadě další jeho výhodou je jeho snadná implementovatelnost a také velmi dobrá dokumentace a podpora. To, že pro velký provoz není tak rychlý jako Nginx, pro tento systém není zásadní.

Pro samotnou instalaci webového serveru Apache v operačním systému Ubuntu stačí jediný příkaz v terminálu. Před instalací je dobré zkontrolovat a případně aktualizovat instalační balíčky.

sudo apt update && sudo apt install apache2

Po instalaci byl ještě nakonfigurován firewall, tak aby byl povolen Apache.

(47)

52

Instalace proběhla v pořádku, což bylo možné zkontrolovat navštívením adresy serveru v internetovém prohlížeči.

6.2. PHP

PHP je skriptovací programovací jazyk. Nejčastěji se využívá k programování dynamických webových stránek v kombinaci například s HTML. Jeho skripty se spouští na serveru a výsledky jsou posílány zpět uživateli. V současnosti je to nejrozšířenější jazyk v oblasti webových stránek. Jeho výhodami jsou například velké množství funkcí (práce s texty a soubory, přístup k databázím), jednoduchost a nezávislost na platformě (PHP skripty můžeme přenášet např. z Linux na Windows většinou beze změn).

6.2.1.Instalace a konfigurace PHP

Jazyk PHP byl vybrán pro tento projekt, protože je to jazyk vhodný pro dynamický web a svou rozšířeností zaručuje i širokou podporu od dalších technologií použitých v této práci.

PHP bylo nainstalováno na server příkazem

sudo apt install php libapache2-mod-php php-mysql

6.3. SSL

SSL je protokol zabezpečující komunikaci šifrováním. Využívá se například pro komunikaci s webovými servery (HTTPS, zabezpečená verze HTTP). Protokol využívá systém dvou klíčů - veřejný a soukromý. Server pošle klientovi svůj veřejný klíč a pomocí něj klient zašifruje informaci a pošle zpět na server. Díky tomu může informaci rozšifrovat jen server, protože informace zašifrovaná jeho veřejným klíčem lze rozšifrovat jen jeho klíčem soukromým.

(48)

6.4. HTTPS

Protokol HTTPS je v dnešní době většinou už běžnou součástí webu. Bylo tedy potřeba ho zajistit i pro tento projekt. Protokol byl zajištěn pomocí certifikační autority Let`s Encrypt, díky níž je to velice snadné. Software Cerbot po správné konfiguraci zajistí získání a následně automatické aktualizování SLL certifikátu pro nastavenou doménu.

6.5. FTP server

K přenosu souborů na server byl zvolen protokol FTP (File Transfer Protocol). Důvodem byla jeho nezávislost na operačním systému, což bylo při vývoji tohoto projektu potřeba. Další výhodou je dostatek klientů usnadňující práci a také předchozí zkušenosti.

Na server byl nainstalován vsftpd (Very Secure File Transfer Protocol Daemon).

6.5.1. Instalace a konfigurace vsftpd

Pro instalaci vsftpd byl zadán příkaz

sudo apt update && sudo apt install vsftpd

Dále byly otevřeny porty 20, 21 pro FTP, 40000-50000 pro pasivní FTP a 990 pro TLS.

sudo ufw allow 20/tcp sudo ufw allow 21/tcp

sudo ufw allow 40000:50000/tcp sudo ufw allow 990/tcp

Následně byl vytvořen uživatel, který je využíván jen pro FTP komunikaci. Tomuto uživateli bylo pomocí úpravy souboru /etc/ssh/sshd_config zakázáno přihlašování přes ssh. Dále se mu nastavil domovský adresář na kořenový adresář projektu, tedy /var/www/whattodo.cz a přidala práva na přidávání a upravování souborů v tomto adresáři.

(49)

54

Uživatel byl připraven a dále bylo potřeba dokonfigurovat vsftpd. V souboru /etc/vsftpd.conf bylo třeba odkomentovat a přidat pár řádků. Nejdříve bylo třeba povolit uživatelům FTP zapisovat soubory na server, což byl řádek s textem write_enable=YES. Dále bylo třeba omezit uživateli pohyb v souborovém systému jen na adresáře projektu, což byl řádek chroot_local_users=YES. Posledním řádkem byl local_umask=022, díky kterému nahrané soubory dostanou správná práva. Nakonec bylo třeba zajistit podporu souborů, které začínají tečkou přidáním řádku force_dot_files=YES. A dále pro umožnění dostatku připojení pasivního FTP řádky pasv_min_port=40000 a pasv_max_port=50000.

Z důvodu bezpečnosti byl ještě využit nástroj openssl k zabezpečení komunikace. K práci s FTP byl zvolen klient Filezilla.

(50)

7. Možná vylepšení

7.1. Odesílání e-mailů

Jako jedno z možných vylepšení by v budoucnu mohlo být odesílání systémových e-mailů.

Jednalo by se o zprávy, které by odesílal server automaticky administrátorovi. Například při přidání místa běžným uživatelem by se odeslal e-mail správci, aby mohl včas zareagovat a místo schválit.

7.2. Responzivita

Administrační rozhraní určené především pro užívání na stolním počítači či notebooku. Styly jsou ale udělané tak, aby se přizpůsobovaly i zařízením s menším rozlišením. Nicméně pro tak malé zařízení jako telefony ještě není připravené. V případě velkého množství přístupů z mobilních telefonů by se dala vytvořit i verze pro ně.

7.3. Správa obsahu propagačního webu

Propagační web obsahuje texty, které jsou v souborovém systému serveru spolu se všemi variantami v cizích jazycích. Nyní se musí měnit přímo úpravou souborů a v budoucnu by bylo dobré, kdyby měl administrátor možnost měnit tyto texty v administračním systému.

(51)

56

8. Závěr

Na začátku byla provedena rešerše existujících aplikací informujících obyvatele města Liberec a turistických aplikací zahrnujících toto město. Na základě toho byla navržena nová aplikace cílená převážně na návštěvníky města s cílem poskytnout co nejvíce důležitých informací na jednom místě a v co nejjednodušší a nejpřehlednější formě.

Pro tuto aplikaci bylo navrženo webové administrační rozhraní umožňující správu všech dat aplikace a byl vytvořen propagační web obsahující základní informace o aplikaci a v budoucnu obsahující případné novinky v aplikaci.

Ve spolupráci s vývojářem mobilní aplikace Michaelou Zámečníkovou byl navržen ideální datový model tak, aby vyhovoval mobilní aplikaci i administračnímu systému.

Společnost zadávající projekt poskytla virtuální server. Pro webové rozhraní bylo na tento server nainstalováno vše, co bylo potřeba pro fungování systému. Jednalo se především o webový server, PHP a FTP.

Na základě návrhu bylo implementováno administrační rozhraní v jazyce PHP. Toto rozhraní umožňuje kompletní správu dat v databázi mobilní aplikace, to znamená přidávání, úpravu a mazání míst či událostí v systému. Registrovaným uživatelům umožňuje přidávat a spravovat vlastní data. Relevantnost dat zajišťuje proces schvalování.

Administrační systém byl otestován. Testovány byly veškeré funkce systému pro všechny uživatelské role. Data přidaná tímto systémem jsou nyní zobrazována v mobilní aplikaci WhatToDo in Liberec, pro kterou byl systém vytvořen. Nyní je systém připraven pro využití v praxi. Zadavatel může začít s hromadným přidáváním dat.

(52)

Seznam použité literatury

[1] SKLAR, David. PHP 7: praktický průvodce nejrozšířenějším skriptovacím jazykem pro web. Přeložil Jan POKORNÝ. Brno: Zoner Press, 2018. Encyklopedie Zoner Press.

ISBN 978-80-7413-363-3.

[2] The definitive guide to firebase. New York, NY: Springer Science+Business Media, 2017. ISBN 978-1-4842-2942-2.

[3] BÖHMER, Marian. Návrhové vzory v PHP: [23 vzorových postupů pro rychlejší vývoj]. Brno: Computer Press, 2012. ISBN 978-80-251-3338-5.

[4] DEVANSWERS.CO. Installing Apache, MySQL, PHP (LAMP) Stack on Ubuntu 18.04[online]. [cit. 2019-04-29]. Dostupné z: https://devanswers.co/installing-apache- mysql-php-lamp-stack-ubuntu-18-04/

[5] DEVANSWERS.CO. Installing an FTP server (vsftpd) on Ubuntu 18.04 [online]. [cit.

2019-04-29]. Dostupné z: https://devanswers.co/installing-ftp-server-vsftpd-ubuntu- 18-04/

[6] DEVANSWERS.CO. Configuring Let’s Encrypt SSL Cert for Apache on Ubuntu 18.04[online]. [cit. 2019-04-29]. Dostupné z: https://devanswers.co/lets-encrypt-ssl- apache-ubuntu-18-04/

[7] SSL protokol. SSL certifikáty [online]. c2008-2019 [cit. 2019-04-29]. Dostupné z:

https://www.ssl-certifikaty.cz/o-certifikatech/ssl-protokol/

[8] Cloud Firestore. Firebase [online]. [cit. 2019-04-29]. Dostupné z:

https://firebase.google.com/docs/firestore/

References

Related documents

Den första raden på displayen visar om enheten är inställd på “CC” likström eller “PC” pulserad ström.. Lägg händerna i vattenbehållarna - vattnet ska endast täcka

Då Agneta Bengtson (C) utsetts till ledamot i Social- och omsorgsnämnden har kommunfullmäktige att utse en ersättare i hennes

Förslag till ny författning - Om stöd till föreningar i Svedala kommun, vilken ersätter författning 3:09 Stöd till föreningsverksamhet för barn och unga i Svedala kommun och

Ordförande konstaterar att tekniska nämnden beslutar att måltidsplanen ändrar benämning till måltidspolicy 2021 för Svedala kommun, samt att reviderat förslag av

Diplomová práce obsažným a racionálním způsobem osvětluje vývoj a možnosti použití různých typů nanovlákenných membrán na dočištění odpadních vod.. Daná práce je

a zamdiuje se piedev5[m na problematiku vz5jemn6 vazby chemickeho sloZeni, vnitini struktury a mikrostruktury zpracovAvaneho materi6lu ve vztahu k jeho ndslednfm deformadnim

Hybridní mobilní aplikace spojuje výhody obou předchozích přístupů, protože je schopna pomocí pluginů (viz Plugin), které lze získat z repositáře frameworku Apache

Teoretickii d6st je logicky dlendnS. Autor popisuje pifrodnf vlSkna rostlinndho pfivodu jejich chemickd sloZenf a mechanickd vlastnosti. Poukazuje na kritickou