Nastavení "pevného" cookies

Ve skladu používají skladníci mobilní telefony s čtečkami. Skladníci často rotují a proto nemají každý svůj telefon, ale vždy na začátku dne vezmou mobil, který je nabitý a připravený.

Potřebujeme ale logovat kdo jaký telefon použil, ať už kvůli evidenci, poškození nebo abychom zjistili kdo telefon nezapojil do nabíječky. V mobilním telefonu používají SW, který je jako webová stránka. Dodavatel nám navrhl, že pokud bychom nastavili manuálně cookies v mobilních telefonech (cookies by bylo tedy jedinečné ID telefonu), tak nám při používání může logovat kdo jaký telefon používá (pro používání SW se musí nejprve přihlásit).

Problém je, že pokud smažou historii, tak se cookies smaže a jsme nahraní. Napadává jak "na pevno" nastavit cookies? Například nějaký doplněk do prohlížeče nebo služba na pozadí, která by při detekci chybějícího cookies opět cookies obnovila? Případně jiné elegantnější řešení?

Jedno z reseni je ulozit do telefonu soubor s informacemi pro identifikaci telefonu, ze ktereho pomoci JS ulozite informace do browser DB a dle nich nasledne vygenerujete cookies, ktera identifikuje telefon. V pripade, ze clovek smaze cookie, vygeneruje se nova z browser DB. V pripade, ze clovek smaze vsechna data (cookies i browser DB), musi pred prihlasenim overit telefon pomoci toho zakladniho souboru, ze ktereho se opet vygeneruji data do browser DB, potazmo cookies a pak se muze user prihlasit. Tim je zajistene to, ze i kdyz nekdo smaze cookies i browser DB, tak ma moznost overit telefon pomoci souboru vygenerovaneho primo pro nej.

Snad to trochu pomuze.

kedze sa loguju cez webstranku, tak mozes kazdemu telefonu nastavit inu domacu stranku kde bude login s tym ze podla url sa identifikuje telefon. cize www.lalal.local/123 identifikuje mobil ako 123

Co třeba změnit user-agent v prohlížeči a identifikovat podle toho?

Nevšlel bych blbosti, běžně se tohle řeší pomocí:
- samostatných účtů v mobilu pro každého zaměstnance (nutná ale vzdálená správa)
- přihlašováním v aplikace, obvykle stačí pouze pár místný pin pro identifikaci
- zámkem (na pin, kartu) pro vzití mobilu ze stojna
- použitím nfc tagu pro odemčení mobilu či aplikace (každý bude mít vlastní)

TomasX: neresi Tve navrhy jen identifikaci usera, nikoliv daneho mobilu, o kterou slo v dotazu? Mozna mi neco uniklo mezi radky...

To ale stačí. Webview v androidu má podporu cookies a pamatuje si je, stač to přes api povolit, drtivá většina generátorů aplikací z webů tohle dělá.

Dotaz je hlavně o identifikaci uživatele.

Bohužel jsem z toho také nepochopil jak identifikovat mobil ale uživatele, asi by bylo dobré zmínit že nejsem vývojář pro Android.

- samostatných účtů v mobilu pro každého zaměstnance (nutná ale vzdálená správa)

I přes vzdálenou správu to přidá hromadu práce, když si představím kolik skladníků je, kolik je telefonů a každému musím vytvořit vždy nový účet (práce na každý den).

- přihlašováním v aplikace, obvykle stačí pouze pár místný pin pro identifikaci

Přihlašování ve webové stránce je, neřeší to ale identifikaci mobilního telefonu.

- zámkem (na pin, kartu) pro vzití mobilu ze stojna

Myslím, že výrazně více nákladné řešení na práci a finance, akorát bychom si přidali více práce.

- použitím nfc tagu pro odemčení mobilu či aplikace (každý bude mít vlastní)

Stejné jako předchozí bod. Namísto využití identifikace mobilu při přihlášení musím řešit nfc klíčenky atd., takže mám daleko víc práce při realizaci i při následném používání

Navrhované řešení jsou tedy náročnější na vytvoření i následnou správu. V reálném provozu je potřeba aby k obsluze nebyl připoutaný další zaměstnanec, to už jej rovnou můžeme posadit za mříž a nechat jej mobily vydávat a přijímat.


---------

Jedno z reseni je ulozit do telefonu soubor s informacemi pro identifikaci telefonu, ze ktereho pomoci JS ulozite informace do browser DB a dle nich nasledne vygenerujete cookies, ktera identifikuje telefon. V pripade, ze clovek smaze cookie, vygeneruje se nova z browser DB. V pripade, ze clovek smaze vsechna data (cookies i browser DB), musi pred prihlasenim overit telefon pomoci toho zakladniho souboru, ze ktereho se opet vygeneruji data do browser DB, potazmo cookies a pak se muze user prihlasit. Tim je zajistene to, ze i kdyz nekdo smaze cookies i browser DB, tak ma moznost overit telefon pomoci souboru vygenerovaneho primo pro nej.

Je možné prosím odhadnout náročnost? Zní to dobře, jen nevím jak náročné to bude abych případně hledal další řešení.

pořád nerozumím tomu proč se snažíš řešit něco co je v androidu běžně řešené a poskytuje k tomu nástroje. Z aplikace si můžeš vyžádat SSAID (aka Android ID), sice k tomu potřebuješ speciální práva u aplikace, ale to není problém odkliknout. Můžeš použít Advertising ID a zakázat jeho přegenerování. Nebo můžeš použít instance ID, které se generuje pro každou instalovanou aplikaci. Tyhle údaje poté předáš do aplikace jako GET parametr nebo ještě lépe jako http hlavičku. Možností je spousta, základem je se podívat do dokumentace Androidu https://developer.android.com/traini.../user-data-ids, rozhodně bych nevymýšlel vlastní řešení, které ti může přesta fungovat a může s ním být řada problémů.

K uložení vlastních data má aplikace k dispozici šifrované uložiště přes DRM API nebo běžnou jednoduchou sql databázi (klasicky key, value storage). Řada aplikaci si při instalaci vygeneruje přes server (http get volání) unikátní ID, které si právě takhle uloží a poté přežije obnovení ze zálohy, stejně tak některé aplikace takhle ukládají token k vzdálené komunikaci s REST serverem, aby se uživatel nemusel znovu přihlašovat.

TomášX: pokud ten "sw" je webová stránka, viz. první příspěvek, tak nic z tohoto nemůže použít.

Pokud to skutečně není nativní aplikace, pak bych šel cestou IP adres, tedy na routeru se každému zařízení přiřadí pevná IP a na serveru ji pak mohu detekovat. Vím, kdo a ze které IP se přihlásil, tedy vím, které má zařízení.

Toto řešení předpokládá, že server je ve stejné síti. Pokud ne, pak je to složitější (proxy, vpn).

Jan Stejskal: z věty "používají SW, který je jako webová stránka" jsem pochopil, že aplikace je obal nad prohlížečem, ale máš pravdu, může to být i webová stránka. Identifikace podle IP adres není špatný nápad, ale webová aplikace musí být v interní síti a nikoliv na internetu, píšeš, v tom případě je pak vhodné použít mac adresu pro přiřazení.

V tom případě je možné použít nějakou aplikaci, která zajišťuje kiosk mode a právě taková aplikace ti zpřístupní i přes JS např. api getSimSerialNumber() podle kterého to můžeš identifikovat. U jednoho klienta jsem viděl https://www.android-kiosk.com, ale zpravidla dnes se všude přechází na nativní aplikace, udělat je není tak těžké a možnosti jsou širší.

Ano, jedná se o webovou aplikaci v běžném prohlížeči Androidu, nikoliv o "vlastní prohlížeč" s webovou stránkou. Server s webem je umístěn v interní síti.

v tom případě návrh s identifikací přes IP adresu (musí být buď pevná nebo udělovaná přes DHCP podle mac adresy) od Jana Stejskala je dobrý nápad a nejspíš vám bude fungovat.

Původně odeslal uzivatel1 ↪

...
Je možné prosím odhadnout náročnost? Zní to dobře, jen nevím jak náročné to bude abych případně hledal další řešení.

To JS reseni je funkcni i mimo vnitrni site a na jakemkoliv zarizeni. Napsat to cele od nuly je na nekolik dnu prace (frontend JS + backend), nasazeni na web je pak otazka "puldne". Uz si ty casy ale nepamatuju presne, je to cca 2 roky, co jsem to psal a nasazoval, dodnes to funguje bez problemu treba na pokladnach.

Pokud jste ale ve vnitrni siti, bude asi IP pro identifikaci dostacujici a mnohem jednodussi.

Původně odeslal skorozacatecnik ↪

To JS reseni je funkcni i mimo vnitrni site a na jakemkoliv zarizeni. Napsat to cele od nuly je na nekolik dnu prace (frontend JS + backend), nasazeni na web je pak otazka "puldne". Uz si ty casy ale nepamatuju presne, je to cca 2 roky, co jsem to psal a nasazoval, dodnes to funguje bez problemu treba na pokladnach.

Jen tak ze zvědavosti, jak z webové aplikace/stránky otevřete lokální soubor? Musel by to udělat uživatel a tím se z toho stává nepraktické řešení.

Původně odeslal Jan Stejskal ↪

Jen tak ze zvědavosti, jak z webové aplikace/stránky otevřete lokální soubor? Musel by to udělat uživatel a tím se z toho stává nepraktické řešení.

Pomoci standardniho html prvku input type file. V pripade, ze není uzivatelovo zarizeni detekovane (nema ani cookies, ani info v browser db), automaticky vybehne okenko pro autorizaci, kde je input type file a tim se da nacist soubor z lokálního disku a zpracovat pomoci JS jeho obsah.

Ještě doplnim, soubor je pro jednoduchost ulozen v nejake hlavni slozce, aby s tim uživatel nemel potize. Třeba "overeni_pokladny/soubor.dat". Ze zkusenosti, za 2 roky se to použilo párkrát, protože lidi většinou (když uz to vůbec udelaji) smažou jen cookies a v browser DB to zustane.

ano, je tady potřeba uživatelská interakce, bez ní to nelze, což nevypadá jako super uživatelsky přívětivé. Překvapuje mě náročnost v několika dnech, tohle by se mělo dát napsat za desítky minut plus integrace do aplikace, pokud je třetí strany, může to být ten největší oříšek.

Původně odeslal TomášX ↪

ano, je tady potřeba uživatelská interakce, bez ní to nelze, což nevypadá jako super uživatelsky přívětivé. Překvapuje mě náročnost v několika dnech, tohle by se mělo dát napsat za desítky minut plus integrace do aplikace, pokud je třetí strany, může to být ten největší oříšek.

Ta narocnost se urcite dá snížit, ale na desitky minut to nevidim Tomasi.

Hodne casu vezme reseni moznych situaci jako napriklad:
- někdo zkopiroval overovaci soubor do svého zarizeni a pokousi se s nim ověřit další zarizeni
- overovani probiha z nepovolenych IP adres nebo domen
- aplikace bezi na vice subdomenach a je třeba overovat jen na nekterych
- ověřovací soubor musí obsahovat unikatni token prideleny při generovani a nejlepe aby nebyl primo citelny pro usera
- na strane serveru je třeba vyresit generovani souboru a jejich evidenci vc. expirace a vazeb na povolene IP
- je třeba zajistit, aby backend system dokazal pracovat s cookies overenych zarizeni

Je toho docela dost, co musí clovek vyresit. JS k tomu ma cca 19k, backend cca 50k kodu. Tech několik dnu na vyvoj je opravdu realnych.

PS: Promin, jsem se uklikl a oznacil Tvuj příspěvek jako podnetny.. ne ze by nebyl podnetny, ale nebyl to uplne umysl u tohoto prispevku :)

Původně odeslal skorozacatecnik ↪

Ta narocnost se urcite dá snížit, ale na desitky minut to nevidim Tomasi.

Hodne casu vezme reseni moznych situaci jako napriklad:
- někdo zkopiroval overovaci soubor do svého zarizeni a pokousi se s nim ověřit další zarizeni
- overovani probiha z nepovolenych IP adres nebo domen
- aplikace bezi na vice subdomenach a je třeba overovat jen na nekterych
- ověřovací soubor musí obsahovat unikatni token prideleny při generovani a nejlepe aby nebyl primo citelny pro usera
- na strane serveru je třeba vyresit generovani souboru a jejich evidenci vc. expirace a vazeb na povolene IP
- je třeba zajistit, aby backend system dokazal pracovat s cookies overenych zarizeni

Je toho docela dost, co musí clovek vyresit. JS k tomu ma cca 19k, backend cca 50k kodu. Tech několik dnu na vyvoj je opravdu realnych.

PS: Promin, jsem se uklikl a oznacil Tvuj příspěvek jako podnetny.. ne ze by nebyl podnetny, ale nebyl to uplne umysl u tohoto prispevku :)

uhf, 50k řádků backend? To je na celou databázi. Děláš to příliš složité, tyhle ověřovací procesy jsou běžné, avšak nic co by mělo zabrat takovou spoustu času, všechno to jsou drobná pravidla. Nemáš tohle náhodou někde veřejně na nějakém webu? Tohle mě zajímá, vypadá to jako zbytečně složitá komponenta, to znamená, že je obrovské riziko tam omylem propašovat chyby...

Původně odeslal TomášX ↪

uhf, 50k řádků backend? To je na celou databázi. Děláš to příliš složité, tyhle ověřovací procesy jsou běžné, avšak nic co by mělo zabrat takovou spoustu času, všechno to jsou drobná pravidla. Nemáš tohle náhodou někde veřejně na nějakém webu? Tohle mě zajímá, vypadá to jako zbytečně složitá komponenta, to znamená, že je obrovské riziko tam omylem propašovat chyby...

Jaj, po dvou letech si to presne nepamatuju, doted to jede, clovek to pak nereis :) Jen jsem predtim mrknul orientacne po velikostech souboru a zapatral letmo v pameti.
Bohuzel uplne verejne to nikde nemam, pouziva se to na kioskach, pokladnach nebo tabletech, ale veknu ne.

Nicmene zkusil jsem vycistit JS od vetsiny komentu a nejakych debug fci a ma to v cistem JS 15k. Jsou to definice 3 trid (..LocalFile, ..Storage a ..Device, kazda ma 8 - 10 metod, cca 190 radku na jedu bez minimalizace kodu), ktere zajistuji hlavni funkcionalitu. Pak k tomu jsou jeste nejake dalsi obecnejsi prototypy, ty jsou ale v jine casti frameworku. Pokud bych to vsechno minimalizoval, asi z toho dostanu 8, nebo 10 k cisteho JS kodu.

Ohledne backendu, tak ten ma taky nekolik trid (z hlavy: token, file, device, ..) a jednoduchou db pro evidenici tokenu a konfiguracnich souboru. Backend resi a) generovani novych config souboru s tokeny, b) spravu devices v backoffice app, c) interface pro dalsi komponenty systemu vyzadujici detekci zarizeni. Take je to navazane na prava interniho systemu (napriklad na zarizeni s kioskem neni mozne spustit zamestnaneckou, ale jen zakaznickou pokladnu atp).

Urcite i ten backend jde minimalizovat, nebo v pripade, ze nebude do takove miry integrovany, bude kod kratsi. Pod treba 15k to ale myslim nedostanes (jeste asi dost otazka frameworku, ve kterem to pises).

je možné, že to je celý velký systém, který dělá spousty věcí. Jsem skeptik a nevěřím tomu, že ověření identity přes soubor znamená více než několik stovek řádků kódu :).

jen pro upřesnění, jak jsem se teď dozvěděl, vyjádření JS k tomu ma cca 19k, backend cca 50k kodu znamená velikost v KB a nikoliv počet řádků, jak jsem se mylně domníval.