Ga naar inhoud
  • 0

lijst van ingelogde accounts/gebruikers


Marsau

Vraag

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?

 

Link naar reactie

13 antwoorden op deze vraag

Aanbevolen berichten

  • 0

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.

 

Link naar reactie
  • 0

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.

 

Link naar reactie
  • 0

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.

aangepast door hans erik
Link naar reactie
  • 0

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….
Link naar reactie
  • 0

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/

Link naar reactie
  • 0
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.

Link naar reactie
  • 0

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.

Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...