Příspěvky

1

Vývoj / Re:Indexování v databázi

« kdy: 06. 12. 2019, 10:10:36 »

Zdravím, pokud mám dotaz zobrazený dole, kde :minDate je objekt typu Date (minimální den v měsíci v daném roce) a :maxDate je objekt typu Date (maximálně den v měsíci v daném roce), tak jak by měli být provedeny indexy na ten datum? Měl by být index pouze uploadDatetime A zvlášt activeStartTime nebo by měl být vytvořen kompozitní index na uploadDatetime a activeStartTime (tedy tohle by tvořilo jeden index...)

Kód: [Vybrat]

TypedQuery<Document> q3 = entityManager.createQuery("SELECT d FROM Document d " +
                "INNER JOIN d.documentsForUsers ud WHERE (d.documentState.id != 0 AND" +
                " ud.sharingType = 1" +
                " AND ud.user.email=:email AND ud.approval != 2 AND" +
                " d.uploadDatetime between :minDate and :maxDate)" +
                " OR(d.documentState.id = 1 AND ud.sharingType.id=2" +
                " AND ud.user.email=:email" +
                " AND current_timestamp > d.activeStartTime AND ud.approval != 2" +
                " AND d.activeStartTime between :minDate AND :maxDate) ORDER BY CASE WHEN ud.sharingType=1 THEN d.uploadDatetime "+
                                        " ELSE d.activeStartTime END DESC", Document.class);
Ta samá otázka u toho druhého dotaz. Jak v tomto případě vytvořit index na datumy? Udělat kompozitní dva uploadDatetime + approvalEndTime a druhý activeStartTime + activeEndTime?

Kód: [Vybrat]

TypedQuery<Document> q2 = entityManager.createQuery("SELECT d FROM Document d " +
                        "INNER JOIN d.documentsForUsers ud WHERE (d.documentState.id = 2 AND ud.sharingType = 1" +
                        " AND ud.user.email=:email" +
                        " AND current_timestamp between d.uploadDatetime AND d.approvalEndTime AND ud.approval=2)" +
                        " OR(d.documentState.id = 1 AND ud.sharingType.id=2 AND ud.user.email=:email AND current_timestamp " +
                        "between d.activeStartTime AND d.activeEndTime AND ud.approval=2) ORDER BY CASE WHEN ud.sharingType=1 THEN d.uploadDatetime " +
                        "ELSE d.activeStartTime END DESC"
                , Document.class);
Děkuji

2

Windows a jiné systémy / Minimální práva pro aplikaci běžící na WIN10

« kdy: 15. 10. 2019, 20:38:52 »

Zdavím,
pod jakými minimální právy ve Windowsu by měla běžet aplikace na PC? Řekněme, že na tom PC běží REST server a potřeboval bych, aby běžela pod minimální právy. Jaká práva by to měla být?

Děkuji

3

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 02. 07. 2019, 19:21:34 »

Přemýšlím, jakým způsobem to udělat na front endu s oauthem2.
1.) Potřeboval bych login a po úspěšném loginu jako být na jiné stránce (index.html) třeba. Čili nápad by byl, že když dostane klient ten access_token, tak se přes JS udělá redirect na ten index.html. Ale řeknemě, že ten login bude první stránka, která se má objevit - třeba mojestranka.cz/login.html - Jak ale zamezím tomu, že si tam uživatel třeba napíše mojestranka.cz/index.html a dostane se na tu indexovou stránku i bez toho tokenu?

2.) Řekněme, že ten token je elektronicky podepsanej. Na klientskou část aplikace bych nahrál public klíč. Jak to potom na té front endové části přeložím do nějaké čitelné formy pro mě?

Děkuji

4

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 02. 07. 2019, 11:00:12 »

Ano, pokud ten token bude uložen v JS aplikaci na frontendu, z pohledu CSRF je to bezpečné – útočník se k tokenu nemůže dostat a prohlížeč ho neposílá automaticky, tj. požadavek s validním tokenem nemůže odejít jinak, než přímo z vaší aplikace.

Pokud se OAuth2 implementuje podle aktuálních doporučení, žádný známý útok mne nenapadá. Jedině to, že u Single Page Aplikací (SPA) se dříve doporučovalo u autentizace přes OAuth2 implicit flow, dnes už se doporučuje provést i v tomhle případě standardní získání tokenu. Celý proces přihlášení přes OAuth2 je odbře popsán teřba v OAuth 2 Simplified a jsou tam i odkazy na aktuální doporučení.

Zdravím,
tak se do toho pomalu pouštím, včera jsem začal studoval Oauth2 a začal trošku i to programovat. Nicméně motá mi hlavu toto...
1) Dočetl jsem se, že má být client id a client secret. A to má být oboje nějak zašifrovaný. Proč?
2) Povedlo se mi udělat, že jsem si vygeneroval certifikát a podepsal na autorizačním serveru privátním klíčem, public klíčem jsem to rozšifroval - ALE... Mám používat cliend id s client secret nebo to podepisování? A nebo oboje? Případně proč?
3) Chtěl bych ještě docílit toho, že se vypočte u těch JWT, zda ten JWT nebyl nějak změněn. Dá se toho nějak docílit?

Ta bakalářka jinak bude o něčem jiném, tamto téma mi neprošlo (neschválilo mi to vedení), takže se to muselo hodit spíše do bezpečnosti.
Případně, mohl bych se Vám takhle někdy zase ozvat, kdybych v něčem byl zaseknutý?

Mockrát děkuji
Mohl bych Vás

5

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 11. 05. 2019, 00:02:24 »

Děkuji.
Čili za předpokladu, že budu používat Oauth2 pro ty rest api, budu mít aplikaci, kdy bude jeden server a jakože "jeden" front end, tak k CSRF nemůže dojít, pokud ten token bude prostě uložený někde v JS kodu na klientovi. Je to takto správně? Já jsem
A existují nějaké útoky přímo na ten Oauth2, na který bych si měl dát pozor?

6

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 10. 05. 2019, 12:12:24 »

Mockrát Vám děkuji. Ta Vaše vysvětlení jsou pro mě (jako člověka, co s tím nikdy nepracoval) velmi pochopitelná.

Děkuji. Pro mne je to důležitá informace, že to vysvětlování má smysl a že to je srozumitelné. Abych si tu jen tak nepsal něco, čemu z 90 % nebude rozumět :-)

Čili navrhujete: Aby REST api bylo zabezpečené přes Oauth2 - tím způsobem, jak jste popisoval. Čili na serveru se vytvoří nějaký elektronický dokument podepsaný, který pošle na klienta a ověřuje ho podle podpisu.

Ano. Ten dokument, který se používá v OAuth2 protokolu, se nazývá JWT – JSON Web Token. Jeho generování a ověřování nebudete implementovat, ve Springu už jsou knihovny, které to implementují. Vy to musíte jen nakonfigurovat (jaké klíče se mají použít apod.) a implementovat věci, na kterých to generování a ověřování závisí. Např. když se uživatel přihlásí jménem a heslem, Spring zavolá vaší službu, které předá to jméno a heslo, vy implementujete vyhledání uživatele v databázi, ověření hesla a zjištění dalších údajů o uživateli (třeba jeho plné jméno a role) a tyhle údaje vrátí vaše služba Springu, a ten už z toho ten JWT vyrobí.

A FB/Google přihlášení byste do toho nedoporučoval? Že jste psal, že se bude míchat Oauth2 na dvou nesouvislých místech?

Že se to bude míchat na dvou místech bylo myšleno tak, aby vás nemátlo, že se ten protokol může v té aplikaci použít dvěma způsoby, které spolu nijak nesouvisí. Je spoust aplikací, které používají OAuth2 pro zabezpečení svých REST služeb, a přihlášení přes FB  nebo Google neimplementují. A naopak je spousta aplikací, které implementují přihlášení přes FB nebo Google, ale jiným způsobem OAuth2 nepoužívají.

Já osobně bych doporučoval v takové aplikaci mít implementované přihlášení minimálně přes FB, Google, MojeID a asi i Twitter, protože zejména u aplikací, které používám jen občas, je otravné přihlašovat se jménem a heslem. A to používám správce hesel, takže pro mne je to přihlášení jednodušší, než pro většinu lidí, kteří si musí nějaké heslo vymyslet a pak si ho pamatovat. Ale to přihlášení přes systémy třetích stran je volitelná funkce, dá se doplnit kdykoli později – spíš je to další funkce, kterou můžete přidat, když se budete chtít naučit něco dalšího.

A pokud by se mi podařilo do té aplikace toto implementovat + to hashování hesla + ty role, tak by to dle Vás bylo bezpečnostně v pořádku? Samozřejmě ještě nevím, co s tím https potom...

Z hlediska autentizace by to mělo být v pořádku, protokoly, o kterých se bavíme, jsou prověřené, implementace použitá ve Springu pokud vím nemá žádné známé bezpečnostní problémy. Jinak je ale potřeba bezpečnost řešit u každé části aplikace, nedá se říct, že by aplikace použitím nějaké technologie byla bezpečná. Vždy musíte počítat např. s tím, že uživatel v prohlížeči sice může zadat např. jen číslo, ale schopnější uživatel si umí z prohlížeče ten JWT vytáhnout a zavolá tu vaší RESTovou službu jinak, a místo čísla tam dá text nebo ho nevyplní vůbec. Aplikace v takovém případě má vypsat chybu ale hlavně nesmí udělat žádnou operaci, na kterou uživatel nemá oprávnění.

Aplikace ve Springu se myslím většinou nevystavují přímo do internetu – obvykle tam bývá předřazený proxy server (třeba Nginx). Na tom předřazeném serveru se nakonfiguruje HTTPS (a přesměrování z HTTP na HTTPS), ten proxy server pak už může komunikovat se Springovou aplikací nešifrovaným HTTP – běží buď na stejném serveru nebo ve stejné síti. A i kdyby ta Springová aplikace měla (sama) běžet přes HTTPS, je to jen otázka konfigurace, té aplikace se to nijak nedotkne. Ve frontendové části aplikace se HTTPS vyřeší ještě snadněji, tam jde jenom o to v URL pro volání RESTových služeb použít protokol https a ne http. A samozřejmě je potřeba i tu frontendovou aplikaci servírovat ze serveru přes HTTPS – u malé aplikace to může dělat ten samý server, který dělá proxy server té backendové Springové aplikaci. Tj. pak máte třeba Nginx server, na něm je nakonfigurované HTTPS a s tím serverem komunikuje webový prohlížeč. Ten Nginx jednak poskytuje (statické) soubory frontendové aplikace, a jednak určité URL (třeba https://example.com/api/*) přeposílá na tu backendovou aplikaci ve Springu.

Zdravím,
a jak to ještě funguje s CSRF? Řekněme, že bych použil Oauth2 k zabezpečení těch REST služeb. CSRF hrozí? Případně mu předpokládám je vhodné nějakým způsobem zamezit?

Děkuji

7

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 28. 04. 2019, 14:38:41 »

Mockrát Vám děkuji. Ta Vaše vysvětlení jsou pro mě (jako člověka, co s tím nikdy nepracoval) velmi pochopitelná. Čili navrhujete: Aby REST api bylo zabezpečené přes Oauth2 - tím způsobem, jak jste popisoval. Čili na serveru se vytvoří nějaký elektronický dokument podepsaný, který pošle na klienta a ověřuje ho podle podpisu. A FB/Google přihlášení byste do toho nedoporučoval? Že jste psal, že se bude míchat Oauth2 na dvou nesouvislých místech? A pokud by se mi podařilo do té aplikace toto implementovat + to hashování hesla + ty role, tak by to dle Vás bylo bezpečnostně v pořádku? Samozřejmě ještě nevím, co s tím https potom...

8

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 28. 04. 2019, 12:43:59 »

Jo a ještě jedna věc...
U Rest Api jsem koukal, že je anotace @Secured(role) - jakým způsobem se přenáší ta role mezi springem a front endem? Uložená v jsonu nějak?

9

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 28. 04. 2019, 12:39:47 »

Použít jen HTTPS (a z HTTP udělat jen přesměrování na HTTPS) je jen otázka konfigurace webového serveru. Autentizaci přihlášením klientským certifikátem přes HTTPS bych nedělal, podpora v prohlížečích je špatná. Ne že by to neodporovaly, ale UX je otřesné. Například Chrome vyžaduje od uživatele každých pár minut PIN k čipové kartě s uloženým certifikátem, pokud se používá TLS 1.3, protože dohodnutí nových parametrů TLS dělají opravdu důkladně až k té nové žádosti o PIN.

Pokud použijete jen jQuery, musíte si napsat sám spoustu věcí, které vám jinak poskytují ty frameworky. Angular je už dost velký framework, myslím, že by stačilo i něco lehčího – třeba Vue.js. Myslím, že se ho člověk naučí docela rychle a postará se za vás o ty dvě nejnudnější věci, které musíte pořád řešit v čistém JavaScriptu – propojení dat v JavaScriptovém objektu na HTML prvky (vstupní políčka formulářů a výstup) a spouštění akcí.

Pro autentizaci volání RESTových služeb jsem navrhoval použít protokol OAuth2, který k RESTovým požadavkům přidává JWT –JSON Web Token. V něm jsou zakódované údaje, které předal autentizační server, jsou jím podepsané a obvykle obsahují časovou značku. Autentizační server tedy vystaví JSON, ve kterém je uvedená identifikace uživatele (nějaké ID, login, e-mail apod.), může tam přidat další údaje jako třeba role uživatele a nastaví platnost tokenu třeba na 15 minut a celé to podepíše. REST server pak ověří podpis a časovou platnost toho tokenu a vytáhne si z něj potřebné údaje (např. ten login).

Hesla se na serveru nešifrují ale hashují, tj. z hashe nelze zpět získat původní heslo. Existují speciální hashovací funkce určené pro hesla, kterým tedy já osobně moc nevěřím, protože nejsou kryptograficky prověřené. Takže bych raději použil standardní SHA-256. Důležité je to, že se nehashuje samotné heslo, ale kombinace heslo+sůl+pepř. Sůl je nějaký náhodný text unikátní pro každé heslo a je uložený spolu s heslem. Pepř je také náhodný text, který ale vůbec není uložený v databázi, je někde v konfiguraci aplikace. Kdyby útočník získal databázi, nebude znát pepř a nemůže tedy zkoušet hesla hádat. Kdyby získal databázi i pepř, může zkoušet hesla hádat – zkusí nějaké heslo, k němu zná pepř i sůl, vypočítá hash a porovná ho s tím v databázi. Díky soli ale musí hádat každé heslo zvlášť. Když se nepoužije sůl ani pepř, může útočník použít tzv. duhové tabulky – tabulky, kde je ke spoustě hesel už vypočítaný hash. Pak mu stačí projít databázi a všechny uložené hashe hledat v těch duhových tabulkách. U jednoduchých hesel uspěje a získá tak hesla konkrétních uživatelů. Pokud byste chtěl o bezpečném ukládání hesel vědět víc, hodně o tom píše a přednáší Michal Špaček.

Co se týče SQL injection, takovou chybu musíte spíš pracně vyrobit – sám, nebo použitím nevhodného nástroje. SQL injection vzniká tak, že v programu skládáte ručně do textového řetězce SQL příkaz a jeho parametry. Třeba "SELECT * FROM table WHERE id = " + request.getId(). Když použijete JPA nebo Spring JDBCTemplate a parametry budete do SQL dotazů předávat pomocí mapování, SQL injection nemůže nastat (samozřejmě pokud není nějaká chyba v použitých knihovnách a nedělají to skládání řetězců interně v té knihovně).

Pro uživatelské role máte nejjednodušší použít Spring Security – poskytnete implementaci, která pro zadaného uživatele vrátí seznam jeho rolí, a pak už jenom stačí každou metodu REST controlleru označit anotací, ve které uvedete seznam rolí, které tu metodu smějí volat.

Děkuji.
Jednu věc nechápu. Bavíme se o autentizaci přes OAuth2 a k tomu by měl být i možný způsob autentizaci i normální, že? Jakože klasická registrace na straně té aplikace.
Řekněme, že se uživatel přihlásí přes FB. Jak to ted bude reálně fungovat? Řekněme, že tam bude prostě úvodní stránka, kde se danému člověku budou vypisovat nové události ze všech společenstev, ve kterých je členem.
Čili by byl dotaz na DB - "neco... WHERE user.id = X;" - nicméně když se přihlásí přes FB, tak jak tohle zjistím, když toho člověka vlastně fyzicky v databázi nemám, ne? Tak jak zjistím, do jakých společenstev se přidal, na jakých bude akcích atd, když ho fyzicky v databazi mít nebudu?

10

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 27. 04. 2019, 14:03:51 »

Našel jsem k https tohle
https://www.baeldung.com/spring-boot-https-self-signed-certificate

To by šlo použít s rest api dohromady?

11

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 27. 04. 2019, 13:40:37 »

A jakým způsobem bych řešil komunikaci té aplikace pomocí jenom https? Potřebuji to řešit jako celou aplikaci, ne jenom na straně springu.
Každopádně jsme zapomněl zmínit, že neumím react ani angular, takže bych to dělal v core javascriptu + jquery. Ale to by mělo jít také v pohodě, ne?
Takže tedy navrhujete implementovat ze zabezpečení aplikace:
- Ouath2
- JWT
- šifrování hesel
- nějaké obecné zabezpečení REST api
- asi by to chtělo nějakou ochranu proti těm běžným útokům ne? SQLinjection například? Nevím, zda spring to nějak defaultně nekryje, ale pokud ne, tak takové věci by tam asi měly také být.
- role. Pracoval jsem s nimi v celé springové aplikaci, přes rest nevím, jak to funguje a jestli to vůbec nějak jde...

Co jsem koukal, tak kdyby to nebylo přes rest, ale všechno ve springu psané, tak by se to https dalo přímo nastavit na straně springu...

Co si o tom všem myslíte?

Děkuji

12

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 26. 04. 2019, 19:33:21 »

děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky

Psal jste, že byste použil REST s AJAXem. To zapadá do mé představy, jakou by taková aplikace měla mít architekturu – na backendu Spring, který bude veškeré služby poskytovat přes RESTové API, a jako frontend klasická SPA, která bude volat to RESTové API. Mně by se pro tu frontend část nejvíce líbilo Vue, ale klidně to může být třeba Angular nebo React.

Má poznámka k RESTu pak směřovala k tomu, aby to RESTové API bylo navržené tak, že může fungovat i samostatně, bez té webové aplikace. Často se totiž stává, že když se navrhuje RESTOvé API pro jednu konkrétní SPA, je to API s tou frontendovou aplikací natolik svázané, že prakticky nejde jinde použít. Tady by ale myslím bylo vhodné, aby cokoli, co půjde udělat přes webový frontend, šlo (bez větší námahy) udělat i voláním API. Například klasický postup přidání nového člena spolku by byl takový, že to nějaký administrátor spolku nakliká přes webové rozhraní. Ale spolek už má třeba jinou evidenci a chtěl by používat jiné funkce té aplikace – tak si udělá propojku, která přes to RESTové API bude vytvářet členy na základě toho druhého systému.

Multitenant znamená, že se aplikace provozuje jenom jednou (typicky jen s jednou databází), ale z hlediska uživatelů se to chová, jako kdyby to bylo víc nezávislých aplikací, pro každý spolek jiná. Např. můžete mít jednu instalaci účetního programu, vede se v ní ale účetnictví několika firem. Z pohledu uživatelů se to chová, jako by účetnictví každé firmy bylo zvlášť – nesmí se tedy stát, že by účetní jedné firmy viděl nějaké údaje z jiné firmy, nebo že by si i navzájem mohli jenom měnit konfiguraci.

Nejsnazší by samozřejmě bylo mít pro každou firmu/spolek jinou databázi, jenže to je zejména ve webovém prostředí obtížně řešitelné – pokud byste měl na jednom serveru třeba 100 databází, těžko může server udržovat třeba 400 spojení do databáze (pro každou databázi 4), která by byla většinu času neaktivní. Druhá možnost je mít vše ve společných tabulkách, prakticky v každé tabulce pak tedy musí být i sloupec určující, do které firmy daný záznam patří. Pak je samozřejmě potřeba ve všech dotazech přidávat i podmínku na aktuální firmu, aby se právě nestalo, že se někde zobrazí i údaje někoho jiného. To je jedna nevýhoda, druhá nevýhoda je, že se pak jednotlivé firmy ovlivňují více, než je zdrávo – když budete mít devět firem, každá bude mít deset faktur, a desátá firma bude mít deset tisíc faktur, penalizované za to, že pracují s tabulkou o desetitisíci záznamech (což je tedy pořád málo, ale v jiných tabulkách může být těch záznamů řádově víc), budou všechny firmy. Většina relačních databází pak umožňuje ještě něco mezi, že se připojujete k jedné databázi, ale uvnitř ní je víc prostorů, které jsou do jisté míry oddělené. Třeba v PostgreSQL by se pro tohle dala použít schémata.

Ale zároveň to není věc, která by tam musela být za každou cenu hned od začátku, asi to není věc, která by se řešila na úrovni bakalářské práce. Ale dá se s tím počítat třeba na úrovni API – třeba účetnictví Flexibee to má dělané tak, že první položka cesty v URL je vždy identifikátor firmy. Takže třeba pro seznam faktur Firmy1 voláte https://www.example.com/firma1/faktury a pro seznam faktur Firmy dva voláte https://www.example.com/firma2/faktury. Mimochodem zrovna Flexibee má docela pěkné API, ve kterém jde udělat skoro všechno, co umí ta aplikace samotná.

Pokud byste měl nějaké další dotazy, klidně se ptejte. Já budu rád, když taková aplikace konečně vznikne a nebudu jí muset příště psát znova sám :-)

Zdravím,
potřeboval bych k tomu ještě vymyslet pořádné zabezpečení té aplikace. Napadlo by Vás něco, co by se dalo (z toho balíčku security) implementovat? Respektive co by ta aplikace měla mít, aby byla opravdu bezpečná?
Samozřejmostí by mělo být https a šifrovaná hesla - nicméně:
Pokud bych používal REST api, tak https na straně springu těžko nastavím, že?
Co jiného, kromě https a šifrování hesla by se k tomu dalo přidat?

Děkuji

13

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 15. 04. 2019, 19:22:59 »

Různé spolky, které mají jednotky až desítky členů, obvykle potřebují vést evidenci svých členů spolu s kontaktními údaji a často pak potřebují svým členům po přihlášení poskytnou něco z následujícího:

• Zobrazit kontaktní údaje ostatních členů (e-mail, telefon, Facebook, poštovní adresa…).
• Umožnit členům přihlásit se na nějakou spolkovou akci.
• Nechat členy hlasovat třeba o termínu akce nebo barvě triček.
• Vyexportovat seznam členů nebo jen některé údaje (třeba jen seznam e-mailů) do Excelu, CSV, vytisknout prezenční listinu všech členů nebo jen těch přihlášených na akci (vygenerovat PDF).
• Rozeslat členům e-mail na základě nějaké šablony (třeba s platebními údaji).

Pokud má spolek ve svých řadách nějakého programátora, obvykle na to udělá nějakou webovou aplikaci, která splní minimum toho, co je potřeba. Takže takových aplikací budou po republice desítky, místo aby byl jedna dotažená a open-source, kterou si každý přizpůsobí podle svých potřeb. A nebo se to řeší různými tabulkami posílanými e-mailem, Google tabulkou, Doodle apod.

Tak můžete začít s tou opensource aplikací, ke které se později budou moci připojit ostatní :-)

Protože má zároveň každý jiné požadavky, bylo by fajn, kdyby to bylo postavené nad zdokumentovaným RESTovým rozhraním, aby se na to případně daly napojovat další systémy. Mělo by to být multitenant, aby se to na jednom serveru dalo provozovat pro víc spolků. Může tam být implementováno přihlašování pomocí OAuth 2.0 (Facebook, Google, MojeID atd.) A různých dalších vylepšení se tam dá navymýšlet spousta.

děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky

14

Vývoj / Přístup k Wi-Fi přes javu

« kdy: 15. 04. 2019, 19:05:29 »

Zdravím,

chtěl bych se optat, zda moje myšlenka je vůbec možná, případně jak proveditelná v jazyce java.

1.) Komunikace s Wi-Fi přes javu. Jde to? Případně jak toho docílit?
2.) Pokud bod 1) je reálný, jak mohu získat MAC adresy připojených zařízení? Případně jak to udělat přes javu?

Díky

15

Studium a uplatnění / Nápad na bakalářskou práci se Spring

« kdy: 15. 04. 2019, 13:28:44 »

Zdravím,
mám sehnaného vedoucího práce, který by mi vedl bakalářku v tomhle směru. Ale problém je, že mě nenapadá nějaké zajímavá aplikace ve springu (mvc, security, hibernate atd)  + javascriptu. Zřejmě bych použil i REST s AJAXem, nicméně přesné zadání mě úplně nenapadá...

Jediné, co mě napadlo je - převod desktopové aplikace na webové v javě - to znamená udělat desktopovou verzi, webovou, možnosti přenosu, zabezpečení atd...

Napadlo by vás něco prosím, nějaké téma, aplikace související s tímhle tématem?

Díky moc