lijst van ingelogde accounts/gebruikers

[Marsau]

Beste mensen, 

Een terugkerend onderwerp... Dat m.i. aan belang wint als je systemen 'socialer' wilt ontwikkelen...

Ik zoek een charmante mogelijkheid om de gebruikers een (zo veel mogelijk) realtime overzicht te tonen van de alle ingelogde gebruikers. Dit moet de samenwerking ten goede komen, en ook nieuwe functionaliteit mogelijk maken. Standaard is het in Filemaker niet mogelijk om per file een gebruikerslijst te tonen, maar met het nieuwe data API zie ik wel mogelijkheden (maar heb nog niet doorgrond hoe precies...)

Ik heb eerder dit eerder geprobeerd te realiseren met 'sessie'-records, waarbij elke gebruiker een record krijgt bij inloggen, te verwijderen bij uitloggen of server side opschonen na een periode van inactiviteit. Werkt wel, maar omslachtig en nooit helemaal accuraat. En verre van charmant.

Welke benaderingen passen jullie toe, of wat denken jullie ervan?

 

[Banach]

Ik denk dat je hier wel het nodige uit kunt halen. De tool is gratis en open.

https://thebrainbasket.com/?p=549

 

[Marsau]

Dank je wel. Ik kende deze al, maar was eigenlijk benieuwd naar verdere toepassing. Of wellicht andere benaderingen.

[menno]

Hi Mars, ik heb je even een PB gestuurd met wat nieuwe info  

[hans erik]

Ik gebruik de oplossing dit jij ook hebt uitgevogeld, Mars.

De gebruiker logt aan en krijgt een $$sessionID (= UUID) en maakt een logrecord aan met een status. Die status wordt bij bepaalde activiteiten telkens bijgewerkt (d.w.z. de timestamp). Lastig is alleen dat niet iedereen 'netjes' uitlogt. Dus je moet ook kijken naar de datum ofzo.

 

[Marsau]

Inderdaad, je moet een soort server-side opruimscript hebben dat 'oude' kaarten verwijderd - en wat is dan 'oud'? Bovendien is inactiviteit niet per se absentie, dus per ongeluk zou zo'n sessie-record onterecht verwijderd kunnen worden.

Ik heb het redelijk werkend, maar accuraat is anders. 

Het idee van sessiekaarten dient overigens ook een ander doel. Een persoonlijke sessierecord kan je een 'Algemeen' tabel hanteren met alleen maar velden tbc interface, zonder risico op record-locking, gevaar van verwijdering etc. 

Een meer accurate oplossing - althans voordat Filemaker deze functionaliteit zelf ooit gaat verzorgen - is de Admin API. Met hulp van Menno heb ik een paar oplossingsrichtingen kunnen verkennen. Je kan (per bestand) een user- en/of accountlist genereren, en dat zelfs als een tabel in het systeem verankeren. Een serverside script (om de 60 of 120 sec) houdt alles synchroon. 

Kijk er al een weekje naar, en het werkt vlekkeloos.

 

[Banach]

Is het misschien een idee om die oplossing hier te delen?

[hans erik]

Ik gebruik mijn 'tracking' ook om te signaleren of gebruikers 2x ingelogd zijn met hetzelfde ID.

Dat werkt doordat ik bij sommige navigatiestappen (bijv het wisselen van een layout of tabpanel) een check doe op het aantal SessionID's dat dezelfde status heeft (dwz combinatie van account en status).  De check is dan door een relatie op timestamp toe te voegen.

Als er 2 gebruikers actief zijn met dezelfde login, spelen ze qua 'timestamp' als het ware 'haasje over' je krijgt dus niet voortdurend een waarschuwing, maar alleen wanneer de ander een latere timestamp heeft dan jij. Op die manier hoef ook geen oude records op te ruimen: die blijven immers in het verleden hangen. De timestamp in de logfile wordt bijgewerkt met de sessionID.

Edited January 22, 2019 by hans erik

[hans erik]

Mijn oplossing is denk ik toch iets anders dan die van Menno of Mars.

Ik heb het als volgt ingeregeld:

 

- Gebruiker A logt in met account XXX, krijgt een UUID als sessionID.

- Bij openen vh projectscherm vult een script automatisch een global veld met ‘active XXX’. Via een relatie op sessionID maakt hij een record aan in de logfile met een automatische timestamp_modification

- Bij elke navigatieactie die ik wil loggen werkt het script de logrecord even bij. Dus elke keer verspringt de timestamp_modification in de logrecord.

 

Als gebruiker B ook inlogt met XXX krijgt ie een andere sessionID, en maakt een andere logrecord aan.

Op dat moment zijn er 2 logrecords met dezelfde status ‘active XXX’, maar elk met een eigen sessionID en timestamp.

 

- als een van beide gebruikers iets doet, bijv switcht van tabpanel oid, wordt de check gedaan:

- een tweede global field heeft een timestamp en via een relatie op ‘active XXX’ en de timestamp_modification (global_timestamp < timestamp_modification) wordt gekeken of er al een recentere logentry is met dezelfde status.

- zoniet => prima, zo ja => melding.

- en uiteraard wordt daarna de logrecord bijgewerkt, gevolgd door een update van de global_timestamp.

 

Doordat je alleen signaleert als iemand anders een recentere logentry heeft, sluit je gelijk uit dat een sessie per abuis niet goed is afgemeld. Je hoeft dus geen oude meuk op te ruimen….

[menno]

Met de adminAPI haal ik "de informatie" van de server op. Dat is een JSON met alle bestanden die leesbaar zijn voor FMS, geopend of niet. Verder staat er in die JSON welke clients er zijn ingelogd en welke bestanden ze gebruiken.

Die JSON haal je vervolgens uit elkaar in bestanden, clients en clientbestanden. Dan weet je precies wie welk bestand in gebruik heeft en dat kan je op verschillende manieren toonbaar maken in de bestanden (als je dat wenst). 

Ik post het voorbeeldje expliciet niet, omdat de adminAPI in Beta is en 27 sept. a.s. ophoudt te werken (erg vervelend trouwens, dat deed FMI ook al met de betaversie van de dataAPI). In April of Mei zal FM18 uitkomen en daarvoor maak ik dan een definitieve versie en die zal dan met een leuk begeleidend artikel weer op FileMakerTips zijn te vinden.

Tot het zover is kan je de documentatie van de adminAPI zelf bekijken op https://<jouweigenfilemakerserver>/fmi/admin/apidoc/

[Banach]

Ik kijk al uit naar april of mei ?

Edited January 22, 2019 by Banach

[Marsau]

10 uur geleden zei hans erik:

Mijn oplossing is denk ik toch iets anders dan die van Menno of Mars.

Ik heb het als volgt ingeregeld:

 

- Gebruiker A logt in met account XXX, krijgt een UUID als sessionID.

- Bij openen vh projectscherm vult een script automatisch een global veld met ‘active XXX’. Via een relatie op sessionID maakt hij een record aan in de logfile met een automatische timestamp_modification

- Bij elke navigatieactie die ik wil loggen werkt het script de logrecord even bij. Dus elke keer verspringt de timestamp_modification in de logrecord.

 

Als gebruiker B ook inlogt met XXX krijgt ie een andere sessionID, en maakt een andere logrecord aan.

Op dat moment zijn er 2 logrecords met dezelfde status ‘active XXX’, maar elk met een eigen sessionID en timestamp.

 

- als een van beide gebruikers iets doet, bijv switcht van tabpanel oid, wordt de check gedaan:

- een tweede global field heeft een timestamp en via een relatie op ‘active XXX’ en de timestamp_modification (global_timestamp < timestamp_modification) wordt gekeken of er al een recentere logentry is met dezelfde status.

- zoniet => prima, zo ja => melding.

- en uiteraard wordt daarna de logrecord bijgewerkt, gevolgd door een update van de global_timestamp.

 

Doordat je alleen signaleert als iemand anders een recentere logentry heeft, sluit je gelijk uit dat een sessie per abuis niet goed is afgemeld. Je hoeft dus geen oude meuk op te ruimen….

Ik vind het een fascinerende oplossing, Hans Erik. Ik weet alleen niet of je werkelijk krijgt - of kunt destilleren - wat ik bedoel: een lijst van actieve gebruikers.

[hans erik]

Nou ja, niet 100% betrouwbaar. Je kunt altijd alle logrecords opvragen die aan bepaalde criteria voldoen. Als een gebruiker aanlogt, maakt ie een 'login' record aan. Logt ie uit (via een knop of met een trigger op het sluiten vh laatste venster), dan wordt een loguit record aangemaakt. Lastig is iemand die gewoon zijn pc uitzet. Dan krijg je die trigger niet. En ook een webdirect client geeft wel een login maar niet altijd een loguit. Maar je ziet natuurlijk wel wie er de afgelopen x minuten actief is geweest.

[Marsau]

Ja, ik zie het voor me. Mooie van je aanpak is dat je eigenlijk ook echt activiteit registreert. Dat heb je met de adminAPI benadering weer niet: die toont 'slechts' het bestaan van een connectie.