Jump to content
  • 0

Werken met Accounts & Privileges kan geld kosten!


Rony Rabijns

Question

Posted

Neem volgende praktijkopstelling :

In een verkoopsysteem wordt afhankelijk van de aankoopprijs van een artikel, de aankoopprijs vermenigvuldigd met een bepaalde coëfficient om de verkoopprijs te kennen. Hoe hoger de aankoopprijs, hoe lager de coëfficient. Vanaf een bepaalde aankoopprijs ligt die coëfficient vast.

 

In Filemakerees wordt dat dan :

case(

aankoopprijs <= conditie 1 ; aankoopprijs * parameter 1 ;

aankoopprijs <= conditie 2 ; aankoopprijs * parameter 2 ;

aankoopprijs <= conditie 3 ; aankoopprijs * parameter 3 ;

aankoopprijs * parameter 4

)

 

De velden conditie_n en parameter_n zitten in een aparte tabel die gerelateerd is aan de hoofdtabel met de aankooprijzen via een trigger-relatie (een altijd-geldende relatie)

 

Als je die opstelling bouwt in Filemaker, werkt dat perfect.

 

Maar omdat bepaalde verkopers de condities niet mogen kennen, moeten die velden ontoegankelijk zijn. Bepaal daarom via een PrivilegeSet in Accounts & Privileges dat de velden Conditie_n niet toegankelijk zijn. Ken die set toe aan bijvoorbeeld de gebruiker GAST.

 

Log nu in als GAST en kijk wat er gebeurt :

Alle berekeningen waarin de velden conditie_n gebruikt zijn, kloppen niet meer. Filemaker voert een berekening uit, zonder aan te geven dat ie dat eigenlijk niet mag berekenen omdat hij niet voldoende privileges heeft. Maw Filemaker voert die Case() uit, neemt de laatste voorwaarde en berekent daarmee de verkoopprijs. Een doorsnee gebruiker rekent dat resultaat niet na en verkoopt dus lager dan de normale verkoopprijs !

 

Ik heb de test gedaan in Filemaker 6, 7 en 8. Telkens de bestanden van scratch gebouwd, telkens dezelfde fout. Dat is dus iets wat er al jaren in zit, en ik heb dat nog nooit gehoord, gemerkt, gelezen, ....

 

Ik had als resultaat een vraagteken verwacht of een andere melding, maar zeker geen berekening die "op het eerste zicht" klopt. Ik heb dit voorbeeld gesimplifieerd, want in de praktijk zijn de condities complexer en bevatten meer berekeningen. Daardoor heb je zelfs geen idee wat de mogelijke verkoopprijs zou zijn. Als Filemaker dan een getal als resultaat geeft, ga je er vanuit dat dat ook juist is. Mooi niet dus !

 

Wie heeft dezelfde ervaring of wist dit al ?

De bug zit 'm dus in het gebruik van gerelateerde velden die ontoegankelijk gemaakt zijn. Filemaker beschouwt die velden als zijnde 0.

In dit voorbeeldje door het gebruik van een Case() ziet FM de kans schoon die 0 te overroepen en doet dan ook gewoon. Zonder boe of bah ! Ik vrees dat er met een If() hetzelfde gebeurt ...

 

ik heb een voorbeeldje (FM7 / FM8) bijgevoegd waarmee je kan testen.

NoAccess.fp7.zip

Recommended Posts

  • 0
Posted
Wie heeft dezelfde ervaring of wist dit al ?

 

Nooit gerealiseerd dat het dit resultaat kon hebben.

 

Ik had als resultaat een vraagteken verwacht of een andere melding, maar zeker geen berekening die "op het eerste zicht" klopt.

 

Dat lijkt me niet helemaal terecht, want in dit geval

 

...zit 'm dus in het gebruik van gerelateerde velden die ontoegankelijk gemaakt zijn...

 

kan het ook zo zijn dat er geen gerelateerde waarden zijn en dan neemt FM ook 0 aan als waarde.

 

Ik begrijp je schrik, maar als je voor gebruik relaties controleert op geldigheid, dan zou dit geen probleem moeten geven. FM geeft terug dat er geen gerelateerde waarden zijn als ze door privileges onbereikbaar zijn.

 

Zou het 'expected behaviour' kunnen zijn?

 

rmw

  • 0
Posted
FM geeft terug dat er geen gerelateerde waarden zijn als ze door privileges onbereikbaar zijn.

 

Heb ik getest. En hier heb je een punt. Dat is inderdaad een "workaround". Maar .... wel een heel vervelende ! Aangezien je dan in iedere berekening eigenlijk zou moeten gaan checken of een eventueel gebruikte relatie geldig is. En dat kunnen er veel zijn in één enkele berekening ... !

 

Het ware een betere oplossing geweest zoals ze gedaan hebben met de scripts : Ik kan bepalen dat iemand met minder privileges toch alles mag uitvoeren in het script, ongeacht de privilege-instellingen.

 

Zou het 'expected behaviour' kunnen zijn?

Misschien, misschien niet. Wat mij betreft niet.

  • 0
Posted

We kunnen er wel eens mee lachen, maar ik blijf het "bad behaviour" vinden.

 

Deze "fout" steekt al jaaaaaaren in Filemaker. God weet hoeveel developers hier al in gelopen zijn, ZONDER het te weten ! Wij zijn er tenslotte vandaag ook maar heel toevallig op gestoten ... En ik loop toch ook al een aantal jaren rond in het Filemaker-wereldje ...

  • 0
Posted

Dag Ronny,

 

ik begrijp je frustratie: FileMaker laat ons iets te vaak in de steek met vitale informatie over de status van bepaalde parameters. Of het nu gaat om security of relaties: (zie ook: http://www.clarify.net/viewtopic.php?p=19393#19393)

 

Ik hoop dat FileMaker Inc. in de toekomst meer inspanningen zal doen om dergelijke valkuilen (waar dagelijks waarschijnlijk wel mensen intuinen) beter te documenteren.

 

Veel groeten,

 

Joris

  • 0
Posted

@ Joris, rmw,

 

Ik blijf een beetje op mijn honger zitten :

Jullie lopen toch ook al een tijdje rond in het Filemaker-milieu, maar wisten jullie van deze fout ?

 

@ Andere ontwikkelaars

Iemand al iets gelijkaardigs vastgesteld ? Graag reactie.

 

Wij beginnen ons namelijk zorgen te maken over een aantal zaken :

- Waar zit die fout nog ingebouwd in operationele applicaties ? (dat kunnen wij alleen beantwoorden)

- Zijn er nog gelijkaardige fouten in Filemaker die me van mijn stoel doen vallen ? (dat hopen we van jullie te vernemen)

  • 0
Posted

Ik heb hetzelfde aan de hand gehad, wij hebben hier de organisatie omheen gezet om de juiste tellingen door de juiste persoon te laten verkrijgen.

Het opstellen van een prijzenboek mag dus alleen gebeuren door degene met voldoende rechten.

 

Valt overigens goed uit te leggen, wat je niet ziet, rekent hij ook niet mee.

 

Daarnaast is het testen van dit soort onderwerpen een aandachtspunt.

Elk rapport MOET na te rekenen zijn, al is het middels een Excel sheet.

 

Maar de praktijk leert dat vrijwel niemand een programma echt goed controleert, tenzij het aantoonbaar geld heeft gekost....

Dan controleren ze ook niet meer, dan zijn ze boos en mogen wij dat weer zien te herstellen...

 

Ik heb het geluk een aantal gebruikers te hebben met boekhoudkundige preciesie. Vierkantstellingen, aansluitingen, afrondingsproblemen, we hebben ze allemaal gehad.

Zozeer zelfs dat we afrondingsfouten in de programmatuur van anderen ontdekten :lol:

  • 0
Posted

Als je geen rechten hebt tot een veld dan krijg je dat veld, nog de waarde van dat veld nooit te zien.

 

De waarde die FileMaker in zo'n geval teruggeeft is een lege waarde. Het zo een serieuse security risk zijn, mochten we met calculaties plotseling waarden van een veld kunnen tevoorschijn toveren.

 

Je hoeft heus geen hocus pokus calculies gebruiken om te testen of een veld beschikbaar is of niet. De functie isValid(), is de functie die je hiervoor moet gebruiken.

 

IsValid geeft 0 terug indien:

- een veld verkeerde waarden bevat (vb tekst in een tijdsveld)

- een veld al dan niet tijdelijk (en dat is wanneer je geen rechten hebt het gevolg) beschikbaar is. Een gewist veld zou ook de oorzaak kunnen zijn.

 

Geen rechten op een veld, wil dus weldegelijk zeggen, geen rechten op een veld: geen truken, geen foefkes, geen workarounds ...

En dat kan ik alleen maar toejuichen.

 

 

Koen

  • 0
Posted
@ Joris, rmw,

 

Ik blijf een beetje op mijn honger zitten :

Jullie lopen toch ook al een tijdje rond in het Filemaker-milieu, maar wisten jullie van deze fout ?

 

Ik houd het erop dat het niet fout is. Het is, net als met het draadje van Joris over cascading delete, wel iets om goed rekening mee te houden.

 

Dat we soms graag willen dat FM zich anders gedraagd zou tot 'feature requests' moeten leiden, maar dat is weer een heel andere discussie.

 

rmw

  • 0
Posted
Als je geen rechten hebt tot een veld dan krijg je dat veld, nog de waarde van dat veld nooit te zien.

 

De waarde die FileMaker in zo'n geval teruggeeft is een lege waarde. Het zo een serieuse security risk zijn, mochten we met calculaties plotseling waarden van een veld kunnen tevoorschijn toveren.

 

Maar dat is het nu precies: FileMaker rekent de formule wél uit, en geeft wél een resultaat, alleen is dat totaal verkeerd, omdat één van de elementen ontbrak. Daarom krijgt de gebruiker met beperkte toegang een ander getal te zien dan degene die full access heeft. En dat zou niet mogen: FileMaker zou iets moeten tonen als "no access" of "this calculation can not be evaluated". We zouden zelfs al blij geweest zijn met het gewone vraagteken. Maar niets van dat alles.

 

Er is dus wel degelijk een probleem, en een heel groot.

 

Dat van die IsValid klopt natuurlijk wel. Maar je kan niet elke calculatie daarop gaan testen, stel je voor... Moet je er dan vanuit gaan dat geen enkele calculatie te betrouwen is? In FileMaker? En ook in Excel?

  • 0
Posted (edited)
...Aangezien je dan in iedere berekening eigenlijk zou moeten gaan checken of een eventueel gebruikte relatie geldig is...

 

...FileMaker rekent de formule wél uit, en geeft wél een resultaat, alleen is dat totaal verkeerd, omdat één van de elementen ontbrak...

 

...case(

aankoopprijs <= conditie 1 ; aankoopprijs * parameter 1 ;

aankoopprijs <= conditie 2 ; aankoopprijs * parameter 2 ;

aankoopprijs <= conditie 3 ; aankoopprijs * parameter 3 ;

aankoopprijs * parameter 4

)...

 

Als de condities gerelateerd moeten worden bepaald en er zijn geen gerelateerde gegevens dat is 'aankoopprijs * parameter 4' toch het goede antwoord?

 

Blijft wel de volgende vraag:

Er vindt een optelling over gerelateerde gegevens plaats en met Full Access vind ik er 20 en het totaal is 100.

Met gast toegang zijn er maar 10 toegankelijk en dat levert een totaal van 50 op.

 

Is het antwoord aan de gast-toegang-gebruiker dan goed?

 

rmw

Edited by Guest
  • 0
Posted

Hoeft soms helemaal niet zo fout te zijn....

 

Stel dat ik een gebruiker alles laat printen wat hij maar kan zien, moet de optelsom dan toch alles zijn wat altijd in de database zit?

 

Hetzelfde heb je met totaaltellingen op velden: alleen de set gevonden records moet geteld worden, niet de optelsom van alle aanwezige records in het bestand...

 

Als je dan toch records beschikbaar stelt, dan kan je de velden op 2 manieren beschermen:

a. via rechtenstructuur op veldnivo (doe ik dus nooit!)

b. via layouts die je wel of niet beschikbaar stelt (doe ik dus altijd!)

  • 0
Posted
Bepaal daarom via een PrivilegeSet in Accounts & Privileges dat de velden Conditie_n niet toegankelijk zijn. Ken die set toe aan bijvoorbeeld de gebruiker GAST.

Kan je niet de velden toegankelijk maken en enkel inzien van de tabel voorkomen.Heb iets gelijkaardigs voor recepten maar verberg de formules en een gast kan niet naar layoutweergave en zodoende de betreffende data niet zien.Heeft dan geen gevolg voor calculaties.

Heb hier voordien ook eens gepost ivm vreemd gedrag calculaties en autoinvoer calculatie als privilege beperkt wordt.Full acces berekend onmiddelijk autoinvoer,gast berekende pas na handmatig commit.Oplossing Gastaccount dik kruis geplaatst :D

  • 0
Posted
En dat zou niet mogen: FileMaker zou iets moeten tonen als "no access" of "this calculation can not be evaluated". We zouden zelfs al blij geweest zijn met het gewone vraagteken. Maar niets van dat alles.

 

Ik kan hier wel wat in volgen. Maar het lijklt dan weer allemaal erg conditioneel, afhankelijk van wat je wil testen of calculeren.

 

 

 

Maar je kan niet elke calculatie daarop gaan testen, stel je voor... Moet je er dan vanuit gaan dat geen enkele calculatie te betrouwen is? In FileMaker? En ook in Excel?

 

Dit klopt, en dat hoeft ook niet en 90% van de toepassingen. Maar als je weet dat je toegang gaat beperken met privileges, dan moet je daar rekening meehouden. Maar dat is even goed in scripts zo. Als je een go to layout doet, naar een layout waar je geen rechten op hebt, blijft FileMaker ook staan op de huidige layout en gaat hij dus niet naar een andere layout.

 

Als je daar geen rekening mee houdt krijg je ook vreemde zaken.

 

ik denk dat de schrik er vooral komt, omdat het niet expliciet staat aangegeven in de Filemaker help.

 

 

Koen

  • 0
Posted

Hello,

 

ik sluit me bij Murtje aan: het gedrag op zich is te begrijpen. Security is bij uitstek een materie die goed moet worden voorbereid en waar een duidelijke strategie moet worden gevolgd. Plannen van calculaties hoort daarbij.

 

Maar ik ben het er ook mee eens dat FileMaker beter mag documenteren wat er exact gebeurt in een bepaalde context.

 

Veel groeten,

Joris

  • 0
Posted

Er wordt hier op het forum rond het probleem heen gewandeld naar mijn bescheiden mening. :?

 

Stel je volgende situatie even voor :

Developer A ontwikkelt een applicatie.

Na x aantal jaren is de klant niet meer tevreden over Developer A en gaat op zoek naar een andere Developer, zijnde Developer B.

Er wordt aan Developer B gevraagd om een veld ontoegankelijk te maken voor bepaalde logins.

 

Ik ben er van overtuigd dat tot gisteren, "iedereen" onder ons naar Accounts & Privileges ging, de aanpassing deed en terug buiten wandelde. Zich van geen kwaad bewust.

 

Ik stel me nu de vraag wie de verantwoordelijkheid durft dragen in dit laatste geval. Developer B ? Moet die alle calculaties in alle omstandigheden gaan narekenen ? Moet ie er het DDR bijnemen ? Daar wordt je ook niet veel slimmer van (in geval van Filemaker 6) ...

  • 0
Posted

Dag Ronny,

 

Nu haal je een ander heikel punt aan: het overnemen of 'depanneren' van een klant met een applicatie die niet van jou is. De klant wil snel een oplossing en is niet bereid om uren analysetijd te betalen. Ondertussen loop je als developer natuurlijk een enorm risico.

Ik heb ook minder goede ervaringen gehad met kleine depannages die onvoorziene gevolgen hadden. De verleiding is vaak groot om snel in te grijpen en de klant tevreden te stellen. Het resultaat is soms het tegendeel.

De beste oplossing is om de verantwoordelijkheid vooraf duidelijk op papier af te bakenen, denk ik.

 

Veel groeten,

 

Joris

  • 0
Posted

Er is een mogelijkheid om ergens (volgens mij bij accounts and privileges) de checkbox "run scripts with full privileges" aan te kruisen. Zou dat de oplossing zijn?

  • 0
Posted

Dat vind ik een ander discussie, Rony. (maar daarom niet minder interessante)

 

In elk geval moet een ontwikkelaar altijd testen wat de gevolgen zijn en ook de klant de software laten testen, die laatste kent tenslotte zijn gegevens het best. Een snelle aanpassing om rapkes iets te fixen isvaak geen goeie oplossing. Zeker als je applicatie niet kent. Maar iedereen onderons laat zich er aan vangen, om de klant te "helpen".

 

Koen

  • 0
Posted

Hoe dan ook: FileMaker evalueert in een calculatie een referentie naar een onaccessbaar gegeven als leeg ("" als je wil) wat op zijn beurt als "False" wordt geevalueerd in een Case() functie. Het ware beter dat zoiets geevalueerd wordt als "?", zoals bijvoorbeeld de Evaluate() functie doet als ze een ongeldige formule voor de kiezen krijgt.

 

OK, we maken een bug report, en de volgende release is dat zo...:o)

 

Stel dat FileMaker echter zo'n functionaliteit wijzigt, en een developer REKENDE op deze functionaliteit (veld niet accessbaar -> calc result = ""), dan gaat deze functionaliteit ook weer breken, en gaat FileMaker weer andere mensen ongelukkig maken. En dat willen we ook weer niet.

  • 0
Posted
Hoe dan ook: FileMaker evalueert in een calculatie een referentie naar een onaccessbaar gegeven als leeg ("" als je wil) wat op zijn beurt als "False" wordt geevalueerd in een Case() functie. Het ware beter dat zoiets geevalueerd wordt als "?", zoals bijvoorbeeld de Evaluate() functie doet als ze een ongeldige formule voor de kiezen krijgt.

Ik onderschrijf dit voor de volle honderd percent. Als het zo was geweest, hadden de gebruikers, meteen na het ontoegankelijk maken van de coëfficiënt-gegevens gezien dat er geen berekeningsresultaat meer was. Nu kregen ze gewoon wel een resultaat dat ze bleven betrouwen zoals vroeger (ze wisten niet eens dat ze geen access meer hadden tot een veld in een databank die ze toch nooit zagen). En dat er geregeld prijswijzigingen waren, dat wisten ze, dus viel het niet op dat de prijzen anders waren...

  • 0
Posted
Hoe dan ook: FileMaker evalueert in een calculatie een referentie naar een onaccessbaar gegeven als leeg ("" als je wil) wat op zijn beurt als "False" wordt geevalueerd in een Case() functie. Het ware beter dat zoiets geevalueerd wordt als "?", zoals bijvoorbeeld de Evaluate() functie doet als ze een ongeldige formule voor de kiezen krijgt.

 

Blijft nog steeds de volgende vraag:

Er vindt een optelling over gerelateerde gegevens plaats en met Full Access vind ik er 20 en het totaal is 100.

Met gast toegang zijn er maar 10 toegankelijk en dat levert een totaal van 50 op.

 

Is het antwoord aan de gast-toegang-gebruiker dan goed?

 

rmw

  • 0
Posted

Is het antwoord aan de gast-toegang-gebruiker dan goed?

 

Nee, natuurlijk niet: een offertecalculator die een prijsvoorstel naar een klant toestuurt, wordt verondersteld de juiste prijzen mee te delen, ook als hij geen inzicht heeft/krijgt in de opbouw van die prijsstructuur zoals die door andere afdelingen van zijn bedrijf is opgezet.

  • 0
Posted

 

Is het antwoord aan de gast-toegang-gebruiker dan goed?

 

rmw

 

Ja natuurlijk wel! (sorry, AvD :wink: )

Stel dat hij zijn eigen omzetgemiddelde wil berekenen en slechts gegevens beschikbaar heeft die alleen voor hem bedoeld zijn, dan gaat dit goed!

 

 

Het dualisme dat in deze discussie zit is:

 

a. De gebruiker mag onder geen enkele voorwaarde sommige gegevens gebruiken

b. De gebruiker heeft deze gegevens wel nodig om informatie te produceren.

 

Filemaker is volstrekt helder in deze kwestie. Wat je niet mag krijgen, kan je ook niet mee werken.

 

De verwarring onstaat mede doordat de Database en de Userinterface op één hoop wordt gegooid.

Qua beveiliging moet je onderscheid maken tussen die twee en daar ligt volgens mij het aandachtspunt.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...