Sign in to follow this  
Followers 0
Matt Klein

WebDirect and HTTPS

2 posts in this topic

Now that I'm deeper into my WebDirect solution,  I've come across a question that I can't find a definitive answer for anywhere including forums and official FMI guides.   Doesn't mean it doesn't exist out there.  I've just not been able to find it.

Here it is:

If you want to ensure that data is passing between Web Direct and the browser securely(HTTPS) it seems like it is NOT necessary to turn on "Require Secure Connections" in the Database Server section of FileMaker Server.    It seems like all you need to do is make sure you use HTTPS instead of HTTP in the URL when accessing the WebDirect server.

However,  not turning on "Require Secure Connections" in the Database Server section of FileMaker Server will allow non-secure(HTTP) connections as well as secure(HTTPS).   Turning on "Require Secure Connections" seems to force the HTTPS connection and doesn't allow HTTP connections.

So,   the "Require Secure Connections" in the Database Server section of FileMaker Server doesn't handle the encryption from WebDirect to the browser.   Instead,  the "Require Secure Connections" in the Database Server section of FileMaker Server handles the encryption between the Database Server and the WebDirect server.   The encryption between WebDirect and browser is handled by the Web Server itself and it's merely a matter of using HTTPS or HTTP to determine if the data passing between WebDirect and the browser is encrypted.

Can anyone verify that I'm correct or wrong for that matter? 

Share this post

Link to post
Share on other sites

You seem to have it.


When this option is on, encrypted connections are required; when it is off, encryption is permitted but optional. Encryption is always available if you opt to use it, regardless of this setting. This is why both HTTP and HTTPS work for WebDirect, even with this option turned off.


With this setting enabled, FileMaker Server will not accept unencrypted connections. FileMaker clients (Pro, Go) can detect this and will switch to encrypted connections automatically. Your web server does not detect this, however, and it will not make the same switch. This is why turning this option on doesn't prevent your web server from listening on HTTP, but only HTTPS connections succeed.


You may want to configure your web server to redirect requests from HTTP to HTTPS, in order to eliminate any confusion for your users. There are lots of ways to do this. The simplest might be with an .htaccess file in your web root, if you're using Apache on Mac OS X. You can do it with IIS on Windows, also.


Now, while I'm on the subject… If you're making your WebDirect application available to the public Internet, you might consider implementing a reverse proxy server. A reverse proxy accepts connections from users on the Internet and forwards the requests to a server safely protected behind a firewall, so that people aren't connecting directly to your back-end database server. You can then require SSL for connections from the clients to the proxy, and you can use unencrypted connections from the proxy to the FileMaker server (where you can leave "Require…" turned off). This reduces the load on your FileMaker server by offloading encryption overhead to the proxy, which improves overall performance. If you were to go this route, you'd set up the HTTP->HTTPS redirect on the proxy server. Popular reverse proxies include HAProxy, Squid, and nginx. Cisco firewalls often have a facility for this as well.

For posterity, here's a link to the FileMaker Server 13 security guide:

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By xochi
      Suppose you have a WebDirect database that has both a [Guest] account and regular user accounts.  Is there any way with a special URL or JavaScript to do an automatic [Guest] login that bypasses the filemaker web direct login screen?
      Basically, I want to have a Public area of the site which never asks for authentication, and a members-only are which does, but I don't want to confuse the Public by making them click the [Guest] button ever.
    • By Morenomdz
      Hello there, I've set few text boxes per layout that work as "tutorials", with one button called "help" that changes one global field [tutorial] from Yes to No (and vice versa), commits the record.
      When the global field "tutorial" is set to yes, all the "text boxes" should hide, when it is set to no they should apear. It works perfectly in the fm client but when I got to the web even if I change the field to Yes or No in the client and save the record, the web still shows all the text boxes.
      It looks like the the "hide when" is simple not working. Using 
      table::tutorial = "yes"
      Did a test having the a tex field for the tutorial showing on the layout, it looks like the webdirect is not seeing the field content at all. It shows as empty on web and Yes or No on the client.
    • By jorfasan
      We have a development that if accessed by regular Filemaker Pro the button (via Open URL) that links to a document (word file) it does open the application (MS word) resulting a very satisfactory behaviour for users.
      But the same stuff when running with WebDirect the Chrome gets an 
      "not capable of opening the window; please deactivate the popup window blocker and try again". Well needless to say that that blocker is not active (under preferencies) and the IS manager of the net also verifies it is not blocked at her level. 
      Also firefox, same machine, is not able to open the application; in this case with no alarm / action at all. 
      Any clues??
      - Windows 7 professional, SP1 
      - Chrome: Versión 41.0.2272.118 m
      - Firefox:  36.0.4
      - FM Server:
    • By paul.s
      So, We have a unix admin working on our Mac OSX server. I specifically instructed them not to break our Filemaker 13 Apache install. Well it looks like they worked on the machine but broke one thing.
      Does anyeone know where I should look to fix this?
      What works:
      Webserver servers files fine from the Filemaker HTTP Folders.
      Filemaker WebDirect works fine.
      PHP is working.
      PHP is indicated as ON in FMSA Admin.
      Admin pages at http://localhost:16001/admin-consolework fine.
      Admin screen shows green on Webserver. Indicates PHP is enabled.
      This is the only thing that is not working:
      Previous PHP pages which has successfull connection to databases no longer connect to the database.
      I assume that a reference to filemaker somehow got removed from one of the php config files, but I don't know where.
      Can anyone give me an idea where to look?
    • By LaRetta
      There are several methods for creating standard icons in a file:  regular container, paste the image directly on the layout, use text Webdings ... but recently I have used placing the image in Inspector > Appearance > Background Fill with image.  In this way, the icon can change color on highlight etc. Then this style is saved to a custom theme.
      The advantage is that I can import these 'icons' between files (by importing themes) and I can save them to the theme so it changes throughout a solution automatically.  This is particularly advantageous when I have several companies sharing a single solution because I can change icons to match their theme colors.
      The problem:   When opened in web direct, all I get is a solid-colored square.  I know normally we make separate layouts for web direct but in this current situation, the existing layouts will work perfectly except for a few of these buttons.  And regardless, I would have the same issue on a web direct layout.
      I've tried many different types of icons and images but I am no Images Master and I do not understand the differences in rendering on why images placed in Appearance::background (images) will not work on Web Direct.  Before I give up on this idea for this project, because it is truly my preferred approach, do others have suggestions on image quality or type which might allow this to work?