CDML with FM record level access

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Wouter - 27 Jan 2004 09:45 GMT

Hi,

I am using FM record level access in combination with CDML for a webbased
solutution. It is important that a user can only see his/her own records.
Therefore the password set in the Web security DB is set to be able to only
browse, edit and delete based on limited access in FM. I have a field in
each record that is a multiline text field and the record level access
validation is set to
"PatternCount(WebAccess;External("Web-ClientName";0))>0". This works fine,
even in a large database (>50.000 records). And now for the problem:

As you can see the record level check depends on a function from the web
companion. This is why on the server side the database is started with an
overall password without record level restrictions. The thing that happens
is that when someone is navigating through the webbased solution, it
sometimes happens that in the background the FM database is switched to the
webbased password. This will result in a <no access> message on all records
on the serverside and on the webclient portals with data about the
rescricted file do not display any information anymore (where they where
before off course).
The only way to get rid of this is to physically close the database on the
webserver and reopen it. Even a script that is called from a CDML page that
performs a close/open file action does not work.

Anybody even seen this before and does anybody know what the problem is?

Wouter

Reply to this Message

Tim 'Webko' Booth - 27 Jan 2004 22:42 GMT

> Hi,
>
[quoted text clipped - 13 lines]
> sometimes happens that in the background the FM database is switched to the
> webbased password.

Probably really important to work out why this happens...

> This will result in a <no access> message on all records
> on the serverside and on the webclient portals with data about the
[quoted text clipped - 5 lines]
>
> Anybody even seen this before and does anybody know what the problem is?

I use a slightly different system. Everyone gets a user name and
password in the Web Security database, and all requests are in POST
forms. Then I can use a hidden input to include their user name in every
request, and a tag field on each record.

<input type="hidden" name="OwnerIDTag" value="[FMP-CLientUserName]">

May be of use

Webko
Also, if you need to munge your address, also munge the server name with
.invalid at the end, as your mail server is still handling the spam
before rejecting it, where using .invalid means it nevers leaves the
spammers hijacked server.

Reply to this Message

Wouter - 28 Jan 2004 08:53 GMT

Webco,

> Probably really important to work out why this happens...
I think it happens when a client is cancelling a request by clicking somewhere else before FM is finished handling it (like a large search including a sort).
>
> I use a slightly different system. Everyone gets a user name and
> password in the Web Security database, and all requests are in POST
> forms. Then I can use a hidden input to include their user name in every
> request, and a tag field on each record.
>
> <input type="hidden" name="OwnerIDTag" value="[FMP-CLientUserName]">
I use the same system in addition to FM's record level access in areas where security is less important. I just felt that by only doing it this way it would be a bit to obvious for a user to remove the "OwnerIDTag=Myname" from the address bar to expose all records.
> Also, if you need to munge your address, also munge the server name with
> .invalid at the end, as your mail server is still handling the spam
> before rejecting it, where using .invalid means it nevers leaves the
> spammers hijacked server.
Thanks.

> > Hi,
> >
[quoted text clipped - 40 lines]
> before rejecting it, where using .invalid means it nevers leaves the
> spammers hijacked server.

Reply to this Message

Tim 'Webko' Booth - 28 Jan 2004 23:11 GMT

> > I use a slightly different system. Everyone gets a user name and
> > password in the Web Security database, and all requests are in POST
[quoted text clipped - 7 lines]
> way it would be a bit to obvious for a user to remove the
> "OwnerIDTag=Myname" from the address bar to expose all records.

Which is why I only use POST statements - then the statement doesn't
appear in the URL. But you are right, it is not as secure.

Cheers

Webko

Reply to this Message