Authorisatie

[Optic]

Beste mede-forumleden,

 

Ik heb een applicatie op een Filemaker server versie 9 draaien waar ongeveer 10 clients tegelijkertijd gebruik van maken. Gezien het verschil in ervaring van de werknemers/eindgebruikers wil ik op bepaalde handelingen een beperking voor gebruikers met weinig ervaring. Gezien de aard van de applicatie is dit zeer belangrijk en heb ik bedacht om met zogenaamde authorisatie niveau's te werken, niveau 1 t/m 5. Niveau 1 is onervaren en niveau 5 zeer ervaren/manager.

 

Mijn idee is om aan het begin van een script, welke invloedrijke handelingen uitvoert, het niveau te controleren en te vergelijken met het niveau wat benodigd is om deze handeling uit te voeren. Indien de medewerker aan dit niveau voldoet wordt het script doorgezet en anders afgebroken met een foutmelding.

 

Ik heb zelf bedacht om d.m.v. een login script in de tabel gebruikers het niveau van de gebruiker op te zoeken en deze op te slaan in een algemene variabele.

 

Echter heb ik nog nooit gebruik gemaakt van een algemene variabele in een served applicatie. Mijn vraag is dan ook of dit mogelijk is? Wordt de algemene variabele opgeslagen op de client of veranderd deze constant wanneer een andere gebruiker inlogt?

 

Er zijn natuurlijk talloze manieren om iets dergelijks te realiseren, zou dit de beste benadering zijn? Privellegesets zijn trouwens geen optie gezien de niveau's vanuit de applicatie veranderd moeten worden.

 

Helaas heb ik op dit moment niet de mogelijkheid om het te testen, anders had ik het geprobeerd.

 

Alvast bedankt,

 

Gr. Optic

[rmw]

Ik neem aan dat je aanduiding 'algemene variabele' staat voor een variabele die begint met 2 dollar tekens: $$GebruikersNivo oid

Deze zijn alleen bekend binnen de database waar ze worden gedefinieerd. Dat is denk ik een serieuze beperking.

 

Ik gebruik jou idee voor een script dat de controle doet als volgt:

 

Maak een controlescript in de tabel met gebruikersgegevens.

Als je dat aanroept wordt in een script parameter meegegeven welk nivo aan de handeling is verbonden en welke gebruiker vraagt de handeling te mogen doen.

In het controle script kan je dan gewoon de gebruiker zoeken en het nivo controleren.

Vervolgens geef je in het script resultaat terug of het toegestaan is of niet.

 

Op basis daarvan ga je in je eerste script dan weer verder.

 

Succes!

 

rmw

[BDK]

ik heb het nog weer anders opgelost.

 

ik heb in de gebruikerstabel iedere gebruiker zijn eigen toegangsniveau gegeven en dat wordt gecheckt indien nodig.

 

daarvoor is dan wel een globale relatie nodig met als proprietary key de berekende waarde ‘get ( accountnaam )’ en als foreign key de accountnaam in de gebruikerstabel.

 

groet, bdk

[Optic]

Bedankt voor de reacties.

 

In principe zijn de algemene variabele (Nederlandse Filemaker) alleen nodig in de database waarin ze worden gedefinieerd, echter kan dit wel een beperking worden ja.

 

Ik denk dat ik het volgende toe ga passen:

 

Eindgebruiker triggered een script, stuurt als scriptparameter de ID van de handeling mee, het script zoekt deze handeling op in de 'handelingen tabel' en registreerd het niveau. Zoekt vervolgens de gebruikersniveau op en controleerd dit, vervolgens terug naar de originele lay-out. Wanneer de gebruiker het juiste niveau heeft wordt het juiste script getriggered (aan de hand van de eerder opgegeven script parameter) of men krijgt een foutmelding.

 

Bovenstaande gebruikt geen talloze TO's met relatie's en het niveau van de verschillende handelingen kan achteraf nog gewijzigd worden in de applicatie zelf.

 

Jammer dat het algemene variabele verhaal wat lastig wordt, had een mooie en snelle oplossing geweest.

[rmw]

Misschien nog wel een andere tip:

 

Globale velden kunnen ALTIJD worden benaderd.

Ook als er geen relatie ligt tussen de beide TO's.

Dat zou nog een oplossing kunnen bieden....

 

rmw

[Optic]

Misschien nog wel een andere tip:

 

Globale velden kunnen ALTIJD worden benaderd.

Ook als er geen relatie ligt tussen de beide TO's.

Dat zou nog een oplossing kunnen bieden....

 

rmw

 

Thanks voor deze tip, dat wist ik niet