gegevens opvragen in een protaal en privilege toegang

[Bachje]

Beste mensen

 

ik loop tegen iets aan dat ik niet opgelost krijg....

Doel: het opvragen van studieresultaten van onze studenten uit onze grote studievoortgang database maar we willen ze geen toegang tot die database met gevoelige gegevens geven.

Middel: we hebben een nieuwe database gemaakt met 1 record waarin een student zijn of haar cijfers kan op vragen via een portaal. Dat opvragen moet gebeuren via een student nummer en wachtwoord. Dat werkt.

Probleem: Maar wanneer de student via webdirect (ze hebben immers niet allemaal en FM cliënt) inlogt wordt toch om toegang tot de grote achterliggende database gevraagd. En dat is nu precies wat we niet willen.
We vermoeden dat we iets in het portaal niet goed hebben ingesteld of dat wat we willen misschien helemaal niet kan helemaal niet kan.

Vraag: hoe kunnen we wel de resultaten laten zien mar ze geen toegang tot de achterliggende database geven.

- Misschien is een portaal niet de juiste oplossing? Maar wat dan wel?
- Of is er een manier om die gevens op te halen zonder de toegang....

alvast bedankt....

15 oktober 2023 aangepast door Bachje

[Banach]

Dit kan je op weg helpen:

https://help.claris.com/nl/pro-help/content/creating-editing-privilege-sets.html

[menno]

Je probeert om gegevens te tonen die in werkelijkheid in de achterliggende database staan .... dan hebben ze ook toegang nodig tot die database, daar is met deze werkwijze geen ontkomen aan.

Verder krijg ik de indruk dat jullie de zaak beveiligen met een 'eigen' mechanisme van studentnummers en wachtwoorden die zijn opgeslagen in die nieuwe database.
Die nieuwe database, heeft die inderdaad één FileMaker-account? Als dat zo is, dan is dat per definitie onveilig. Het lijkt me voor jullie verstandiger om de gewenste beveiliging eens uit te tekenen en er eventueel een expert bij te halen.

[Bachje]

Nee de studentnummers en  wachtwoorden zitten in de onderliggende database en worden gebruikt om de gegevens op te halen.

Maar ik vreesde al dat de noodzaak om tot de onderliggende database toegang te hebben noodzakelijk  zou zijn 😓

[Bachje]

Nee de studentnummers en  wachtwoorden zitten in de onderliggende database en worden gebruikt om de gegevens op te halen. WE hebben zowel één account als meerdere accounts geprobeerd maar de vraag om toegang tot de onderliggende database blijft.
Maar ik vreesde al dat de noodzaak om tot de onderliggende database toegang te hebben noodzakelijk  zou zijn 😓

[menno]

Ik heb een klant die een externe klantenservice heeft en die hebben met webdirect toegang tot een bperkt aantal gegevens van de orders, leveringen, facturen, track and trace nummers en het afleveradres.

Hun accounts hebben alleen toegang tot de gegevens die ze nodig hebben in de achterliggende database, maar tot geen enkele layout en geen enkel script. De toegankelijke layouts etc. zitten alleen in de webdirect database. De klanten die contact opnemen met de klantenservice moeten een geldig nummer opgeven van de leverbon, hun klantnummer, ordernummer óf factuurnummer en uitsluitend daarmee kan de klantenservice de gegevens van de klant opzoeken. Zoeken op naam en adres bijvoorbeeld of orderdatum is niet mogelijk. De kracht zit 'm hier in de eenvoud.

[Infomatics]

Je kunt de WebDirect accounts dicht zetten tot het niveau van alleen de velden die je nodig hebt. Hou daarbij wel rekening dat als je via calculaties gegevens uit andere tabellen/velden nodig hebt die ook zichtbaar moeten zijn. Anders geven die calculaties niet de gewenste resultaten. 

[Bachje]

Kun je me een aanwijzing geven hoe en waar ik die webdirect accounts zover dicht kan zetten? en moet dat dan in de oorspronkelijke database? of zou dat ook kunnen met een aparte tabel die de gevens uit de hoofdtabel haalt? En kun je ze dan alleen tot die tabel toegang geven?

alvast bedankt

[Infomatics]

Ik zou een account aanmaken voor WebDirect die je alleen voor deze verbinding gebruikt, zodat je alles wat je niet nodig hebt kunt dichtzetten.

Je gebruikt dus een account WD waar de gebruikers op inloggen en dezelfde account WD in de studievoortgang database.
maar voor het WD account een apart privilege set WD waar je aangeeft welke velden van welke tabellen zichtbaar zijn en dat de layouts en scripts niet zichtbaar zijn.
Als je bepaalde velden niet kunt zien dan kun je stap voor stap meet toegang geven to ze wel zichtbaar zijn, dit zal zijn bij bv calculaties waarbij velden van een andere tabel worden gebruikt. die velden moeten dan ook zichtbaar zijn.

 

[Bachje]

Dank ik ga er eens mee experimenteren

[Marsau]

Nabrandertje van 2ct.

FileMaker heeft toch alle middelen om gebruikers met verschillende gegeven-sets te laten werken. Je kan toegang beperken tot bepaalde layouts (dus tables) en je kan ook in mbv privilegesets heel nauwkeurig toegangsrechten bepalen tot op record/veld niveau. Door het optuigen van twee bestanden neem je dit vraagstuk niet weg, maar naar mijn bescheiden mening is het ook niet echt nodig. Denk bijvoorbeeld aan een opzet waarin een sessierecord met gebruikersID in een globaalveld, waarmee alle relevante gerelateerde gegevens op de layout worden gezet. 

Als het dan toch per se met aparte bestanden moet, kan je een opzet met de DataAPI overwegen. Een aparte FileMaker voor webdirect, met accounts voor de studenten. Data ophalen via API requests op de hoofd-database en de resultaten zichtbaar maken in de front-applicatie. Er wordt dan NIET direct ingelogd op de hoofdapplicatie door de gebruiker, en er hoeft ook niets te worden vastgelegd in de front-applicatie. Complex, - ja een beetje, gedoe, - ja ook, maar wel de prijs voor het hanteren van multiple files waar geen directe koppeling tussen mag zijn.