Native interaction between Web viewer and FileMaker Scripts (Web viewer JS API)

Idea created by MarcelMore on Sep 13, 2016
    Active
    Score101

    THE GOAL:

     

    Using the Webviewer is a promising approach for countless specific cases, which includes:

    - custom made GUIs

    - navigational elements

    - JavaScript Widgets

    - interactive graphics

    - complex calculations that are going beyond FileMakers own calculation capabilities

     

     

     

    THE PROBLEM:

     

    Although there are some hacks and workarounds to provide basic interaction between the Web viewer and FileMaker Scripts, every single approach that has been found so far has a lot of pitfalls, restrictions and there is no technique today that will run on all plattforms (Desktop, iOS, Webdirect).

     

    Existing methods will either make use of FMP URL scheme, which is not suitable for Webdirect because of existing restrictions. Other methods are depending on Plugins that is a dealbreaker for iOS. Although there is no real reason to cut off any platform, because Web viewer depending technologies like HTML, CSS, JavaScript or SVG are platform independend and could/should easily be usable among all given FileMaker use cases.

     

    It is quite obvious that there exists a missing link that prevents the web technologies, living inside the Web viewer, to unfold their full potential in a cooperative use with native FileMaker techniques.

     

     

     

    THE SOLUTION:

     

    If there was a clearly definied API to the Web viewer that would allow secure, flexible and robust communication between the Web viewer and FileMaker Scripts in both directions it would immediately open up a whole new world of possibilities and use cases.

     

     

     

    HOW COULD THIS BE IMPLEMENTED:

     

    Defining and controlling all sorts of interactions within the Web viewer could be achieved in a most flexible and powerful way by JavaScript.

     

    Every Web viewer object could provide a build-in Event handler for JavaScript that allow sending and receiving of predefined messages:

    - WVAPI.runJSscript (with optional Parameter) –> catched by JS listener inside Webviewer to run JS Script

    - WVAPI.runFMscript (with optional Parameter) –> called by JS function inside Webviewer to run Script on FileMaker side

    - WVAPI.sendFieldContentsToFM (with Parameters) –> called by JS function inside Webviewer to populate FileMaker fields with content

     

    These messages could be catched or triggered by self defined JavaScript functions inside the Web viewers content sourcecode.

     

    Parameters would best be defined and passed as JSON-strings for maximum flexibility.

     

    I could imagine that those event handlers are somehow injected/registered into every Web viewer behind the scenes as a given standard set like "onload()" or similar DOM events.

     

    (@FileMaker engineers: You will certainly find some naming scheme that will best fit your existing conventions)

     

     

     

    WHAT ABOUT SECURITY CONCERNS?

     

    Triggering native FileMaker Scripts and Fields from an external source raises security questions.

     

    The described approach should provide a basic authentification scheme for all API calls. Everything else that happens native on the FileMaker side would be controlled by given account rights anyway.

     

    A simple but effective approach to API authentification between FileMaker and Web viewer could be the use of Session tokens.

     

    On the FileMaker side it would need a Script step "setWVAPISessionToken [TokenString]. With this step an internal value is set before any API call could take place from within the Web viewer.

     

    On the WebViewer side every API call must then provide that predefined Session token string as a required parameter.

     

    FileMakers internal Scripting-API for the Web viewer would then compare the predefined stored value with the required API parameter and only continues to run the API call, if both values are identical. Think of it as a kind of passphrase that is required to make an API call.

     

    Providing a Script step to set the session token instead of building it into an own FileMaker dialog setting would allow flexible authentification designs that are controlled by the developer of the FileMaker solution. (e.g. global fixed passphrase vs. User account based passphrase vs. Session based passphrase, etc.).

     

     

     

    FINAL WORDS

     

    Hopefully it is possible to build up a simple, robust, flexible and secure Web viewer API without breaking other technical conventions inside FileMaker.

     

    The described solution may be an elegant way to close the gap by just depending on a few little additions to existing elements.

     

    For a minimal effort there would be some rich and very potential possibilities in reward.