Nastavení pracoviště - problémy se smazáním cookie

Několik let se vede diskuze na uvedené téma, tedy nastavení pracovišť pomocí evidence jednotlivých zařízení, kdy jejich ID se ukládá v prohlížeči do cookie, které se dá celkem lehce smazat. Napadlo mě nakonec celkem jednoduché řešení, které by možná v 95% případů bylo naprosto dostatečné. Tedy:

  1. zachoval bych stávající systém, kdy pokud bude identifikované zařízení, že patří do nějakého pracoviště, tak se pracoviště přiřadí
  2. pokud se pracoviště nepřiřadí, tak by potom mohli mít jednotliví uživatelé na lokální síti identifikované pomocí veřejné IP nastavené preferované, defaultní pracoviště

další vylepšení bych potom navrhoval:

  • pracoviště by mohlo mít přiřazenou barvu a tato barva by se použila jako podklad v kase a dalších widgetech svázaných s pracovištěm
  • pokud by pracoviště nebylo přiřazené, tak by mělo jít v nastavení zakázat zrealizovat doklad například v kase apod.

Díval jsem se na to a mám trochu pocit, že jsi otevřel Pandořinu skříňku…
Celé je to hodně zaprášené a než se s tím začne něco dělat, tak by se to mělo promyslet.

Ideální stav by dle mého byl, kdyby ty cookies nebyly vůbec potřeba a úplně ideálně by se zrušila i ta zařízení.

Podle mne jdou tři různé situace:

  1. Nemám pracoviště a není co řešit. Takto je to ve většině databází.
  2. Jdu “zvenku” někam a to pracoviště potřebuju, aby mi fungovala specifická tiskárna (třeba já mám v některých databázích nastavené pracoviště tak, abych mohl u sebe v kanceláři tisknout nálepky na síťová zařízení). V tomto případě mi na identifikaci pracoviště stačí veřejná IP adresa.
  3. Je to “opravdové” pracoviště, kde se tím nastavuje kde co a které je ve vnitřní síti. Tohle je jediná situace, která je problematická.

Já bych to viděl tak, že přihlašování přes nase-firma.shipard.app bude fungovat jinak v případě, že v databázi existuje pracoviště s danou veřejnou IP adresou. Vsune se tam pokus o stažení nějaké konfigurace ze serveru v lokální síti, kde to pracoviště bude pro danou lokální IP adresu nadefinované. To bude velice rychlé a umožní to do budoucna další věci (třeba nějaký seznam uživatelů na té přihlašovací obrazovce apod.).
Tebe jako uživatele to nijak neomezí, protože chodíš přes shipard.app, kde nic takového nebude.

Další možnost je, že na tom pracovišti by se aplikace spouštěla přes nějaké speciální url typu nase-firma.shipard.app/workplace/id-pracoviste. Stejně to mají někde v záložkách prohlížeče nebo jako ikonu na ploše / v docku (aspoň si to myslím). Při startu přes takového url by došlo k přesměrování na přihlašovací dialog s tím, že by to byl de-facto ekvivalent stažení té konfigurace z předcházejího bodu.

Viděl bych to tak, že by to možná chtělo obě varianty. Ta druhá má výhodu, že není potřeba pevná IP adresa, což se může hodit při aktivaci nějakého záložního připojení. Navíc by to nepotřebovalo ve vnitřní síti žádný server.

Je potřeba, aby se k tomu vyjádřili lidi, co to používají - já opravdu netuším, jak se to na těch pracovištích “startuje”.

Ještě několik poznámek:

  1. Ten seznam uživatelů na pracovišti vůbec k ničemu není, vůbec se to nepoužívá.
  2. Upravit detekci pracoviště tak, aby se ignorovalo zařízení (když je seznam prázdný) je snadné, je to jeden řádek v kódu (to by řešilo situaci 2 - eventuálně v kombinaci s oživením toho seznamu uživatelů na pracovišti).
  3. Pracoviště pořád souvisí s ikonou websocketového serveru (zelený/červený čtvereček nahoře). Než se to začne měnit, mělo by se to nějak dořešit.
  4. Těch zařízeních bych se rád úplně zbavil, v podstatě to k ničemu není a stejně je v tom všude naprostý chaos.

No a úplně nakonec je tady otázka, jak moc je reálné/vhodné/bezpečné tu aplikaci na takovýchto “veřejných” počítačích používat v klasickém browseru. Viděl jsem situaci, kdy něco (předpokládám že nějaké rozšíření chrome) měnilo texty v aplikaci. Docela jsem se vyděsil, ale nevím jak tomu zabránit, když si tam někdo něco nainstaluje a odkliká všechna ta oprávnění.
Takže je tu opět dilema, jestli nezvážit znovu tu desktopovou aplikaci, která by řešila jak ta pracoviště, tak i nesvéprávné uživatele.

začnu jen drobností, na recepci MSI se ten seznam uživatelů používá, protože v mobilní aplikaci se přihlašují kliknutím na tlačítko se jménem a zadáním PINu …

toto by bohatě mohlo stačit i se stávajícím řešením přes cookie, kdy by takové url přiřadilo stávající zařízení do pracoviště …, ale chápu, že bude snaha seznam zařízení úplně zrušit

Celkově se mě nejvíce líbí varianta, že by se dala identifikovat lokální síť, která používá pracoviště pomocí seznamu veřejných IP adres (primární, záložní). Potom by na konkrétní adrese fungoval malý server, který by řídil, která lokální IP adresa patří do jakého pracoviště … Ještě mě napadlo, jestli by se ty pracoviště nedaly řídit VLANama. Tedy, že by pracoviště bylo navázáno na nějakou konkrétní VLANu

No když by se to takto udělalo, tak ta zařízení nejsou potřeba…

Problém je se záložní konektivitou, kde neznáš veřejnou IP adresu - typicky nějaké GSM/LTE/5G.

No tím si nepomůžeš, pořád nemáš jak zjistit žádnou informaci, která by ti pomohla identifikovat v prohlížeči to zařízení (třeba IP adresu v lokální síti).

Vracím se k tématu. Napadlo mě ještě jedno možné a funkční řešení:

  1. zrušit tabulku a seznam zařízení
  2. do cookies ukládat identifikaci pracoviště pomocí url něco jako “https://xyz.shipard.app/mapp/workspace/id-workspace” (kromě /mapp/ by to mělo fungovat i přes /app/)
  3. aby to id-workspace nebylo úplně jednoduché odhadnout, tak by na záznamu pracovitě mohl být nějaký generovaný HASH řetězec
  4. ten HASH by byl taky zajímavý, kdyby administrátor se rozhodnul z pracoviště odstranit všechna zařízení, tak by změnil HASH a měl by jistotu, že z pracoviště vše odhlásil.
  5. nakonec by bylo možné ještě fixovat pracoviště na pevný seznam IP adres (volitelně)