Spring naar bijdragen
  • 0
Marsau

lijst van ingelogde accounts/gebruikers

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?

 

Deel dit bericht


Link naar bericht

11 antwoorden op deze vraag

Aanbevolen berichten

  • 0

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

Deel dit bericht


Link naar bericht
  • 0

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

Deel dit bericht


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

 

Deel dit bericht


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

 

Deel dit bericht


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

bewerkt door hans erik

Deel dit bericht


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

Deel dit bericht


Link naar bericht
  • 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/

Deel dit bericht


Link naar bericht
  • 0

Ik kijk al uit naar april of mei 😜

bewerkt door Banach

Deel dit bericht


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

Deel dit bericht


Link naar bericht

Maak een account aan of meld je aan om een opmerking te plaatsen

Je moet lid zijn om een opmerking achter te kunnen laten

Account aanmaken

Maak een account aan in onze gemeenschap. Het is makkelijk!

Registreer een nieuw account

Aanmelden

Ben je al lid? Meld je hier aan.

Nu aanmelden
×