1 2 Previous Next 20 Replies Latest reply on Oct 14, 2014 4:23 AM by mikebeargie

    WebDirect URL Parameter Passing


      As we all know in FMS 13 v2 FMI removed the option to send URL parameters to WebDirect or script execution and data passing. After searching v3 and v4 there seems to be no sign of this getting re-enabled.


      Does anyone know if this has been activated again or what the road map for this option is?


      We already do something simailar to this from SalesForce to our FM system which uses PHP to shoot in data prior to the opening of a dedicated FM file that then searches for the last entry to act on.

      This would not be a viable solution as we want to use SalesForce to open WebDirect directly.


      Any thoughts would be helpful.

        • 1. Re: WebDirect URL Parameter Passing

          It has not been activated again, nor do I think it will be anytime soon. It was deactivated for security purposes, and FileMaker Inc. has definitely been pushing the security features in the 13 platform. If filemaker's road maps were public, I'm sure there'd be a lot of us devs that would be happy, but I don't think URL parameters would be something to work.


          Your workaround is actually pretty genious (using a CWP page to generate some parameters then immediately process than on WebDirect login), and I think *could* work in WebDirect, as long as you were able to identify the end user somehow. You CAN open up a file directly in WebDirect by using the #_FILENAME_ syntax.


          I would suggest modifying the CWP to record some fairly unique identifier that is accessible via PHP and then again in FIleMaker, once you break that the rest would be easy. I have been looking at the data on panopticlick.eff.org to see if I can find a unique identifier to suffice, and will likely update my blog post on this subject if I find a way to pass the value through.


          Not sure if my blog post on this topic is at all useful:


          • 2. Re: WebDirect URL Parameter Passing

            Hello pblachette and Mike,


            I really like the way that both of you are thinking about this, and I'd like to share an extra idea about it.




            As an upfront caveat:


            I am not a WebDirect user/developer, and this is all just theory, not practice, nothing proven.




            To recap the question that I am focusing on, I'd like to call attention to two important points from your posts:


            1) The FM PHP API can be used to perform a "behind-the-scenes" update to the FileMaker backend.



            2) Per Mike's comment:  We need a means to associate the PHP API call with the WebDirect session:


               - Clearly a shared unique token could unite the two processes.


               - The question that I see is:  How to have that same token be present in both of these apparently separate systems?



            The idea that I'd like to offer is a suggestion for how we might be able to address point #2 above.




            The idea requires:


              - Some kind of UserSessions table in the FMS backend



              - Hosting a PHP page which can use the FM PHP API to write to the UserSessions table


              - A WebViewer on the first layout that the User arrives at when they log in to WebDirect





            How it might work:


            1) Instead of providing the user with a URL to log in to WebDirect, provide them with a URL to the PHP page.



               Let's say that this page is located as follows:   <HOST_FOR_PHP>/Redirector.php




            2) The URL to   Redirector.php  can include any parameters that need to be passed into FM, e.g:


                   If we wanted to pass in department, language, and timezone preferences:




            If there is a need to include a   #DB_NAME   anchor or a  homeurl  param to the WebDirect login URL, these values could also be passed inside the URL to   Redirector.php,   e.g.:






            3) Redirector.php receives this initial request, parses out the passed parameters, and stores them in a PHP session.




            4) Instead of returning page content,  Redirector.php   returns a redirect header which sends the User's browser to the WebDirect login page.


            The redirect URL includes any #DB_NAME and/or homeurl components received in the original request.




            5) The User logs in to WebDirect.



            6) As part of a startup script, WebDirect/FM creates a new record in the UserSessions table.



            7) This new record is seeded with a unique Token value.  This token should not only be unique, it should also be un-guessable.  A serial number would not be appropriate.



            8) Also as part of the startup script, the user is taken to a splash screen layout.



            9) The splash screen layout has a small WebViewer on it.



            10) The URL for the WebViewer is something like:   <HOST_FOR_PHP>/Redirector.php?FmToken=<URL_ENCODED_TOKEN_VALUE>



            11) Redirector.php   receives the request that includes the FmToken value, and also recognizes the User as associated with the PHP session initiated in step #3.



            12) Redirector.php retrieves the FmToken value as a standard GET param.



            13) Redirector.php   retrieves the "Passthrough Params" stored in the PHP session, and uses the FMP PHP API to find and update the record in the UserSessions table which shares the FmToken value.


            Updating the UserSessions table would include storing the Passthrough Params, and also setting a flag indicating completion of this step.



            14) Redirector.php then returns a blank page with a suitable background color to blend into the splash page being displayed in WebDirect.


            Note:  Not sure if WebDirect puts a "mandatory" beveled edge around the WebViewer like IWP used to do, but, if so, Mike's got a great blog post about customizing WebDirect CSS which might be the cure:





            15) Meanwhile, an OnTimer script in the WebDirect session is periodically querying the UserSessions table for the completion flag being set in the appropriate record.



            16) After a configured timeout value, the OnTimer script either gives up and no Passthrough Params are used, or, the Passthrough Data has been found and used as needed.



            17) At this point, a FileMaker script navigates the User to whatever layout they should be on.









            1) Security:


            As we know, the feature to take a user to a target record/layout on login was removed for good reasons.


            It makes sense to limit the above technique to only those cases where the PassthroughData is not anything which will open up a security hole which should have stayed patched.


            I have not thought extensively about any security issues that might exist even if the passthrough data is something as simple as a language preference.


            Ideally, I'd like to see some sharp security minds think this idea through before it gets added to anyone's toolbox.




            2) Development Overhead:


            The above seems like a lot to code up, but, once it has been coded up and proven/tested, it should be fairly easy to modularize and share.




            3) HTTPS:


            In order to prevent security exceptions thrown by the browser, it may be necessary to host the PHP script using https.




            4) "In theory, theory and practice are the same. In practice ..."


            This is all theoretical -- If WebDirect restricts the use of WebViewers in ways that I haven't anticipated, this may not work.


            I wish that I had time to set this up and test it, but right now I do not.







            I sincerely hope you find the above relevant. Perhaps one or both of you has already tried this idea out or have thought it through and found flaws?  If so, I hope you'll share your thoughts/findings.


            Thanks to you both & kind regards,







            Message was edited by: steve_ssh:


               Added point about making token un-guessable.

            • 3. Re: WebDirect URL Parameter Passing

              Steve, this concept is a lot in line with what I had in mind. I am trying to get some free time (a challenge for a home brewer in Oktoberfest season) to work on something, I will most likely have a new blog post out by the time Pause on Error rolls around at the end of October. I’ll post here with any results.

              • 4. Re: WebDirect URL Parameter Passing

                Hey Mike,


                I kind of figured that you were probably already on top of this and maybe had already worked out some of the kinks involved with this.  I look forward to seeing what you come up with and any related blog post.


                Thanks for the reply & best wishes with all the brewing!



                • 5. Re: WebDirect URL Parameter Passing

                  Hi Steve,


                  just wanted to apprise you of my progress. I believe I have worked out a simpler method to pass parameters based on a browser cookie with some PHP, and then retrieving that later after WD login.


                  Basically I've created two files on my server:





                  The WDlogin.php file processes any variables passed via $_GET, (EG WDlogin.php?wdurl=www.site.com/fmi/webd#file&wduser=username&wdpass=password&param1=test1&parametc=testetc) using the $_COOKIE supervariable. The result of this file is to open the webdirect file from the wdurl parameter.


                  Then I set up WDCookie.php to return the contents of said cookie, before destroying the cookie.


                  On the user side, I provide the URL including the parameters for WDlogin.php, which will result in the cookie being set with all the variables I passed. When the WebDirect file is opened, in the login script I will call an Insert From URL step to reference WDcookie.php, which will give me all of the parameters I set in the original URL, and then process those accordingly in FileMaker, including any relogin actions if a wduser/wdpassword parameter exists.


                  Advantages of this method:

                  -Since the data is stored in a cookie, and destroyed after being read out, it's session-specific and user-specific as well.

                  -No need to write parameters to a record with CWP to try and be matched/read by filemaker later on. Since the parameters (which could contain username/password) are never stored outside of memory, it's more secure than writing a record to FileMaker that may be orphaned.

                  -generally context free, with the ability to pass any key/value pair parameter.


                  To do list:

                  -Research/address security concerns.

                  -code additional error checking and test.

                  -write guide and compile for community release.


                  Stay tuned, should have something wrapped up to demo at Pause on Error for anyone interested, with a blog post shortly after.


                  PS - going to try and pack some bottles of my latest batch of homebrew to PoE with me, if anyone finds me there, ask for a sample of my whiskey&vanilla porter.

                  • 6. Re: WebDirect URL Parameter Passing

                    Hey Mike,


                    Bravo for finding a very nice solution.


                    I certainly like how you have eliminated any need for interfacing with PHP and storing a record to hold the payload.  Very elegant.


                    I am somewhat surprised that Insert From URL in WebDirect is going to have access to the browser's cookie data - I would have guessed that the HTTP call happens fom server side without knowledge of the browser's stored cookies  -- *very* cool that this is not the case and that you thought to utilize this.


                    Very best,


                    - steve

                    • 7. Re: WebDirect URL Parameter Passing

                      heh, I hadn't thought about that, but let me make sure that's the case. I only proof-of-concepted the PHP portion of this so far, was still working on the filemaker side, so I'll see what happens. If Insert From URL isn't viable I'll try scraping from a web viewer instead, if neither of those work, a CWP solution and/or generation of some sort of sessionID might still be required.


                      Given that Get(PersistentID) in WD results in cookie data stored by the user's browser, I DO know that WD at least has access to the cookie jar.

                      • 8. Re: WebDirect URL Parameter Passing

                        Hey Mike,


                        Even if Insert From URL is not feasible, I agree that scraping the webviewer is a good second bet.


                        Regardless, I really like your thinking and idea.


                        I think that the real work left in front of you will be the security aspect.  You have both the options of storing the payload in a cookie, and having the second PHP script extract and return the data, and you also have the option of having PHP store that payload in a PHP session, and the second script returns the data from the session.  The former means that the payload data is never stored on a public-facing server except in the case where the user is using some kind of public machine to access the site.  I do not have the background to judge how vulnerable either of these are to attack -- really though, that is the only question that remains in  my mind.  I think one way or another you are very near the finish line to having a cool solution, and that you are sharing it with the community is great.


                        Very best,


                        - steve

                        • 9. Re: WebDirect URL Parameter Passing

                          Added thought:


                          Scraping the webviewer probably means that the PHP scripts would have to be served from the same domain/port as webdirect.   I didn't think about this in my last post -- WebDirect is so FileMaker-client-like in so many respects that it is easy to forget that it has to operate under the same rules that web browsers in general are subject to, including cross-domain restrictions...

                          • 10. Re: WebDirect URL Parameter Passing
                            Mike Duncan

                            Just FYI... WebDirect is not able to get the HTML contents of a web viewer. This was the same restriction as IWP, and will only return the URL of the web viewer. Insert from URL seems like a good bet, will have to test.

                            • 11. Re: WebDirect URL Parameter Passing
                              Mike Duncan

                              After a quick test, I found that insert from URL will work. I came up with some simple php code to set a php session and store whatever GET parameters you pass it, and simply echo that array back out when called. So you can get the parameters passed into webdirect without creating a record.


                              My php looks like this... keeping in mind this is just preliminary testing, also this does not include automatically redirecting just yet... and this must be served on the same domain/port that webdirect is running on.






                              if(isset($_GET) && count($_GET) > 0 ){

                                  $_SESSION['get_requests'] = $_GET;




                              • 12. Re: WebDirect URL Parameter Passing

                                Hi Mike,


                                Thank you for chiming in and sharing your thoughts.


                                Question for you:


                                Were you able to successfully use WebDirect Insert From URL and have your PHP script recognize the PHP session that was initiated in the previous step by the user's browser?


                                Thank you and best,


                                - steve

                                • 13. Re: WebDirect URL Parameter Passing
                                  Mike Duncan



                                  In fact, no. With a little more testing, I see some problems with using insert from URL. I set a php page to echo the session ID from php, and it differs from the session ID that you get when accessing the page directly. For that matter, a web viewer on the layout will show the same session ID as another open tab with the php page loaded directly.


                                  However, insert from URL appears to be initiated by the server, not the users browser. Additionally, I get a different session ID returned every time, which means insert from URL is not storing cookies at all.


                                  So far my testing setup is a little limited, since it is a virtual machine and I have to test everything from a single IP... a limitation of my vm software. I need to test if insert from URL always returns the server's IP, or the client's remote IP. I am guessing it is the server. When I get a little more time, I will try to test it.




                                  • 14. Re: WebDirect URL Parameter Passing

                                    Hi Mike,


                                    This is really great all of the testing that you have done.  Thank you very much, and thank you for posting back the results.  It is how I suspected, though I was hoping otherwise.  Nonethless, the puzzle is still solvable, though, at present, the only means that I see is back to the technique of using the PHP API to update a record.   I'm still hopeful that someone may still see a better way.


                                    Much appreciation to both you and Mike B for working on this.




                                    - steve

                                    1 2 Previous Next