• Annonces

    • Olivier Devriese

      Nouveauté du forum, les blogs !   30/04/2016

      Envie de créer votre blog FileMaker ? Ca ne peut pas être plus simple qu'avec cette nouvelle section du site FM Source qui est désormais plus qu'un simple forum mais un vrai centre de ressource. Vous pouvez aussi facilement l'alimenter en le liant avec le flux RSS d'un autre blog que vous possédez déjà.
  • billets
    90
  • commentaires
    3
  • vues
    2 089

Display Complex Web Viewers in WebDirect

Soliant Consulting

188 vues

This blog post examines the functionality of two of FileMaker’s features and how they work together. The first is the Web Viewer, which is a special layout object that can display web content right in your FileMaker app. The next is WebDirect, which is FileMaker Server’s ability to automatically display your custom FileMaker app in a web browser.

Web Viewers and WebDirect

We have received several inquiries regarding the issue of Web Viewers not rendering in WebDirect. As these techniques become more popular, this may be an issue more developers experience. When first debugging the issue, it was assumed to be a limitation of WebDirect. However, after discussing with co-workers Jeremy Brown and Ross Johnson, a couple workarounds were discovered. The solution discussed here is the simplest and most elegant.

First, the Web Viewer, when shown on a FileMaker Pro layout, runs as its own independent web page, just like you would open a new tab in your web browser and load a URL. However, in WebDirect, content needs to be loaded inside the web page as the content of an “iframe” entity. Iframes are a special type of HTML entity meant to easily specify and display other HTML content to display within that iframe object.

The remote content of an iframe object is referenced as an attribute, at a very basic level, like so:

<iframe src="your_url_here"></iframe>

Seems pretty straightforward, right? However, arbitrarily long URLs or odd characters may cause the iframe to break and not load.

JavaScript Graphs

JavaScript can be a great option to expand the functionality to include just about any type of graph you can imagine and populate it with your FileMaker data.

If you have used JavaScript, such as in Jeremy Brown’s useful Web Viewer Integrations Library,  to display graphs in the Web Viewer via data URLs, you may run into issues when displaying in WebDirect.

Data URIs

You are probably familiar with URLs that start with “http” or https” but there are many other types of uniform resource identifiers (URI). A data URI, instead of including a location, embeds the data to be displayed directly in the document. We commonly use them in FileMaker to construct HTML to display in a web viewer, and avoid network latency and dependencies, including JavaScript.

For example, setting Web Viewer with html, preceding it like this:

"data:text/html,<html>…</html>"

The issue with displaying arbitrarily large or complex data URLs in WebDirect is that the “src” attribute has the potential to break with some JavaScript included as part of the data URI. There is likely an unsupported character or combination somewhere in the included libraries that makes it incompatible with loading as a data URI directly.

What to Do?

Part of the syntax of a data URI allows for specifying the content as being encoded as Base64.

data:[<mediatype>][;base64],<data>

Typically, you would use this to represent non-textual data, such as images or other binary data. In this case, it can still be applied when the media type is “text/html” as well.

This provides a safe way of transferring that html data so it will be unencoded by the web browser, where it is rendered at runtime.

Admittedly, this introduces a little more processing that has to happen somewhere, and can cause a slight delay when rendering in FileMaker Pro vs. not encoding as Base64. However, we can test to see if a user is in WebDirect or not, and direct the output of the Web Viewer appropriately.

Case ( 
  PatternCount ( Get ( ApplicationVersion ) ; "Web" ) ;
  "data:text/html;base64," & Base64Encode ( HTML::HTML_Calc_Here ) ;
  "data:text/html," & HTML::HTML_Calc_Here
)

Note the addition of “;base64” if the application is coming from a “Web” client. With this test, we optimize for both clients and ensure that our content functions everywhere.

Here is the result in FileMaker Pro:
Screenshot of results in FileMaker Pro

Results in FileMaker Pro (click image to enlarge).


The same layout viewed in WebDirect
Screenshot of layout viewed in WebDirect

Layout viewed in WebDirect (click image to enlarge).

You really have to look twice to see what screen shot belongs to which application!

Other Considerations

There are other factors to consider that may cause issues as well. So far, the assumption has been made that all JavaScript and assets are being loaded inline, without externally references. You may still choose to have external references. Just be aware that loading them in an iframe element may behave differently than how they are handled in a FileMaker Pro client.

It is a best practice to have an SSL certificate installed on your production FileMaker Server, and WebDirect will automatically use that certificate as well. That means that, with SSL enabled, WebDirect will redirect clients from HTTP requests to HTTPS. The consequence of that is that all your content must also be secure, as far as your web browser is concerned. A HTTP site can reference HTTPS assets, but not the other way around. Make sure if you have SSL enabled that all external references, such as linked JavaScript libraries, are all referenced with HTTPS as well.

For development servers using a self signed certificate… well, pretty much nothing will load correctly because the web browser will not want to load anything served from a certificate it cannot verify. The main site will load, but not when trying to include content from other sites in the page.

Then there are occasions where you may need to write your own web page to display in a Web Viewer, hosted from another web server entirely. In that case, you may need to enable CORS headers for it to work. Again, in FileMaker Pro clients it works fine, but in WebDirect it loads as an iframe, and becomes a security concern in web browsers to prevent cross site scripting.

How to Support CORS in PHP

If you host your PHP page from the same FileMaker Server, making sure to match http vs. https, then there is no conflict about JavaScript loading from a different source. If, for some reason, you want to have the file load from a different location, you will want to add CORS support in your PHP file as well.

The final PHP file will look something like this:

<?php
// enable cors
// Allow from any origin
if (isset($_SERVER['HTTP_ORIGIN'])) {
 header("Access-Control-Allow-Origin: {$_SERVER['HTTP_ORIGIN']}");
 header('Access-Control-Allow-Credentials: true');
 header('Access-Control-Max-Age: 86400'); // cache for 1 day
}
// Access-Control headers are received during OPTIONS requests
if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']))
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']))
 header("Access-Control-Allow-Headers: {$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}");
}

One other consideration, which I found when using one FileMaker Server to host a file for different WebDirect served solutions, was that there is an added HTTP header that is configured in the default site on FileMaker Server’s web server. This is done for added security for WebDirect to protect against cross site scripting attacks, so you may or may not want to adjust this setting for your needs.

If on a Windows server, you will find this setting in the IIS configuration for HTTP Headers, that it adds a header for “X-Frame-Options” set to require the same origin. If you need to serve this PHP page from a different server, you will need to remove this header as being served by default. Then, in addition to the CORS support, this script will work from different servers. This may be seen as lowering the security on that machine and should probably be avoided by hosting your scripts on a different server, if needed.

References

 

The post Display Complex Web Viewers in WebDirect appeared first on Soliant Consulting.


Afficher la totalité du billet


  Signaler le billet


0 Commentaire


Aucun commentaire à afficher.

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !


Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.


Connectez-vous maintenant