Performing custom search based on user

[dluton]

Please help, I'm completely stuck with this!!

I have a custom web front-end running on our intranet, which accesses numerous databases. Each of the records in the the database will be assigned to an individual; what I need to do is, when a user accesses the database via the web front-end, a FIND is performed based on their access password, and displays ONLY records that have been assigned to that user.

I can do this easily with a script, but this only works when accessing the database through Filemaker itself. I have tried calling the script via an HTML link without success.

Anyone got any ideas?

TIA,

Dan

[Keith M. Davie]

Clearly your solution is for multi-user. Be advised that ScriptMaker is a single-threaded engine which handles one event at a time and which does not queue near-simultaneous requests. Additionally, cdml does not recognize when a ScriptMaker event is not performed by the db, so it advises the client that the transaction was successful.

There are probably other ways to design your solution than with ScriptMaker.

Myself, I handle the situation you describe in a browser using ScriptMaker. Visit my site if you are interested. I handle ScriptMaker scripts successfully while serving them vis-a-vis the browser through FMPro 4.0.v3 on the back-side. It is a complex solution.

[Anatoli]

Script will not work because you cannot identify user and post that info into script.

But the same problem is without scripts as well.

You need to identify visitor and assign the value to Token variable.

That is best achieved via some king of login system -- database.

HTH

[Garry Claridge]

Add the User-name to the search, or is there some sort of calculation?

Garry

[dluton]

How do I add the username automatically to the search though? I don't want to allow users to search for any records that are not assigned to them, you see - if they have to manually select a name then they can just choose anyone's name...

I'm still stumped.

[Garry Claridge]

Is the Username being entered from a form, or is it an http authentication prompt; i.e. initiated from the Web Security Database?

Garry

[Keith M. Davie]

"Script will not work because you cannot identify user and post that info into script."

If you are using Web Security you can capture [fmp-clientusername] and [fmp-clientpassword].

If you don't like Web Security's stylish password window, you can design your own security protocols for tracking clients and passwords and determining access levels.

In both instances and depending on your design creativity, you can certainly use that data such that it is included into a protected script/sub-script scenario. And protected scripts can use/share data with db's which are not set for web sharing, including added security through the capacity for complete removal of data from db's which are set for web sharing.

Many complex ScriptMaker scripts, when handled properly, can be a powerful tool in web solutions, just as they can be in peer-to-peer solutions. Looping ScriptMaker scripts are to be avoided in browser solutions under the current single-thread engine of ScriptMaker.

ScriptMaker scripts can be a useful tool for the creative designer. There are many other tools also available. Solutions are a matter of design.

[Garry Claridge]

Chapter 2 of the 'Web Publishing Security Guidelines' (pdf) gives a description of record-by-record locking. It is at:

http://www.filemaker.com/downloads/index.html

Good Luck.

Garry

[Anatoli]

RE: "Script will not work because you cannot identify user and post that info into script."

If you are using Web Security you can capture [fmp-clientusername] and [fmp-clientpassword].

-------------------------------------------

I've said:

Script will not work because you cannot identify user and post that info into script.

But the same problem is without scripts as well.

You are implying that administrator should separately enter all users into Web Security databases!!

I do not want to do that with more than 100 users.

Better is to provide login system and carry the user ID in Token. You can also carry that ID from IP, but then users cannot use different machine. It will also not work if users are behind firewall and all of them are getting the same IP.

[Keith M. Davie]

Yes Anatoli, I understood what you wrote. And I especially understood this part of it, "...post that info into script." I'm sorry if you misunderstood my post.

The fact is, I agree with you. I did add just one thing, really. "...you can certainly use that data (the client name and password) such that it is included into a protected script/sub-script scenario." Here the key word is "scenario". Perhaps I should have said "schema". This includes not only the database solution, but the browser solution as well. In the database solution it may include creating a record which is deleted with the running of a script, once data from that record is moved or otherwise handled. It may also invlove calculation fields, relationships, portals, etc. On the browser side it may include links, forms, meta redirects which change action tags from the initiating action (e.g. -new to -find or -edit), inlineactions, and those good old fmp-if conditionals controling the text/display. Since one can "carry the user ID in Token", as you suggest, one can insert that token into a db field.

Sometimes a design of intricate complexity weaves a tapestry of elegance for its illusory simplicity.

"You are implying that administrator should separately enter all users into Web Security databases!!"

Perhaps that is what you have inferred. I offered that if one so desired one could use the stylish Web Security protocol (as described in the pdf to which Garry referred), or one can develop one's own tracking protocol.

If one chooses the latter, then the Web Security db would be set for "all users". Yes, that alone leaves one's db's vulnerable to the -format=-raw problem as discussed in the security thread. But as also discussed there, those problems exist within the older versions of FMP even for a db which uses the WS password protocol. I cannot speak directly to 5.5 or 6.0 security. However, as the security thread pointed out, there are other ways to handle security. I believe that you even developed a security protocol for this.

In relation to your concerns for the administrator, the point of developing one's own tracking protocol is that one can then allow the user to determine their own password. And depending on what is desired, a designer could design (with fmp-if conditionals) such that those with special authorities can use a key which will unlock access to certain format files not available to the general public. This, of course, helps provide for the design of a very broad browser solution.

That solution designers have all these tool options I find exciting. The point of my post was the final sentence, "Solutions are a matter of design.".

[Anatoli]

RE: "Solutions are a matter of design.".

Absolutely