Full Acces en toch RecordAcces=1 ipv 2

[rmw]

Graag verneem ik jullie visie op onderstaande.

 

Er is een interface database met een enkele tabel voor wat basisgegevens.

Er is een data database met verschillende tabellen met informatie (transacties, transactieregels, relaties, enz.).

In een van die data tabellen (transactieregels) is via een privilegeset geregeld dat het record alleen gewijzigd mag worden als een bepaald veld de waarde 1 bevat.

 

De interface database bevat layouts waarop de transacties, de regels, de relatiegegevens worden weergegeven.

Ook alle scripting bevindt zich in de interface database.

 

Nu wil het geval dat als iemand aangelogd is met de beperkte privilegeset, er sommige dingen moeten gebeuren via een script die altijd moeten mogen, ongeacht de privileges.

Daarvoor is er de mogelijkheid om een script te draaien met Full Access-privileges (vinkje onderaan het scripteditor venster).

 

Maar.....

 

Helaas wordt alleen de database waarin het script is opgenomen tijdelijk op Full Access gezet en niet de databases waarvan de gegevens worden weergegeven en/of bewerkt.

Als ik in mijn script de privilegeset opvraag en de layout en record-access, is de privilegeset netjes Full Access, de layout access staat op 2, maar record access blijft hardnekkig op 1 staan. Zie hier voor details.

 

Hoewel ik dit in een bijna blanco proefopzetje ook zie gebeuren (ik dacht eerst dat er in mijn complexere opzet een fout zat) en ik me ook kan voorstellen dat het 'intended behaviour' is, vind ik het toch behoorlijk storend. Nu moet ik dus zelf opnieuw inloggen in de data database en, wat lastiger is, ook weer terug naar wat het was, terwijl dat zo mooi door FM geregeld zou kunnen worden.

 

Stelling: een script dat met Full Access draait mag alles, ongeacht in welke tabel de gegevens zich bevinden.

 

Ik ben voor, het maakt het leven een stuk eenvoudiger

 

rmw

[Peter Wagemans]

Een bug fix voor wat je beschrijft lijkt me zeker al vandaag nodig.

 

Stelling: een script dat met Full Access draait mag alles, ongeacht in welke tabel de gegevens zich bevinden.

Dat lijkt me ruimte te geven voor hacking.

 

Ik hoop dat FileMaker ooit op de proppen komt met 1 nieuwe en 1 uitgebreide script stap.

1. De Re-Login stap mogelijk maken op een ander bestand, niet alleen het huidige.

2. Een "Restore Login" script stap. Deze stap zou je dan terug brengen naar de credentials die je had voor een re-login.

 

Nadat je met "elevated privileges" iets doet in een script, dan is het op het ogenblik niet mogelijk om terug af te zakken naar de privileges die je had vóór die re-login. Je weet de account privilegeset wel, maar niet het bijhorende paswoord.

In BSD is dat beter aangepakt:

mbpro:~ peter$ su
Password:
sh-3.2# su fmserver
bash-3.2$ whoami
fmserver
bash-3.2$ 

Gezien je afzakt van de superuser account naar een niet-superuser account, kan je zonder paswoord een re-login uitvoeren.

 

Lijkt me iets voor FileMaker.