9 Replies Latest reply on Feb 19, 2017 8:08 AM by arjen.evertse

    Creating a URL for a single record


      Hi all,

      I'm coming back to FMP after about 20 years away (please be gentle, a lot's changed, I last actively developed in FMP3).

      We have a new db which requires a client to Authorise an order. We'd like to have the authorisation available over the web. Ideally, we would calculate a URL which will take them directly to a very simple Authorisation layout and directly to their specific record. They would click an "Agree" box, press an Authorise button and exit. We don't want them to have to search, just click a URL in an email and go straight to the right place.

      Would it be possible to create this sort of direct access URL - specifying a particular layout and record - with any of the FMP web publishing options?

        • 1. Re: Creating a URL for a single record



          Would open your solution with Webdirect, prompt the user the login and run a script AuthorizeOrder with the $OrderID set to the value in your url. From their you can script the right lay-out, find the right record, etc.


          If Webdirect is the right solution is another question. It depends on how many customers you have, if you want to create logins for them to access this solution, etc.


          For sure it would take to design specific lay-outs for Webdirect and great care when setting up the privilige sets used by the customer accounts to avoid access to data other than what they need.


          Another approach would be Custom Web Publishing, but that requires another set of skills (which I don't have).

          • 2. Re: Creating a URL for a single record

            To build on that:


            The script that sends out the email could create an account name and password to send in the body of the email. It could log the account name and when created and another "housekeeping" script could periodically check for and remove such accounts after a specified interval of time has passed. That would be one way to grant temporary access to the solution if such temporary access is needed.

            • 3. Re: Creating a URL for a single record

              Many thanks, this is what I was looking for - the syntax to build a URL which can control the layout and record. Putting aside possible security issues, is there also a way to pass log-in information via a URL? Each client will have an existing account and if I can eliminate them needing to log in each time it would be good.

              • 4. Re: Creating a URL for a single record

                I like this idea as well. I'll have to take a look at the script steps for account creation as this would be a great way to give temporary access. If I could then build this temporary log in into the URL I would have my complete 'one click' solution.

                • 5. Re: Creating a URL for a single record

                  You can include passwords in the URL and yes it's not a good idea due to being a security risk.

                  • 6. Re: Creating a URL for a single record

                    I'd only do this with a temporary password which had a short expiry (eg. 20 minutes).  It would also have very limited access, probably a row in a separate table with just a boolean field for authorisation and a record ID relating back to the main data record.

                    Does anyone know the syntax for including the log in information? At the very least I'd like to build a simple proof of concept project and see if I think it could work.

                    • 7. Re: Creating a URL for a single record

                      Supplying the login details in the URL is a very bad idea in my opinion, they will even get saved in the browser history.


                      Creating a (temporary) account and supplying the user name and password in the e-mail is more safe. If you really want to avoid the need of login (paying the security price anyway) you can also go with auto login using very restriced privelige set.


                      I personally would probably go for:


                      1: Separate table having OrderID (to relate the confirmation back to your order), Accountname, Expire Timestamp and Boolean field for the confirmation. You can extend this with Confirmation timestamp and other info you want to gather and safe at confirmation. In these situations I like to gather also OS and Browser used so I can see what users mostly used or what a specific user used in case they report a problem.


                      2: A privelige set providing only access to the table mentioned above and only for the records where Accountname matches Get(Accountname).


                      3: Upon generating confirmation your script would create a record in the confirmation table, generate a account with password using the privelige set above, set the expire timestamp and populate the correct URL. Send e-mail to your customer with the URL and login details.


                      4: Run a scheduled script on server that searches for expired confirmation records, loops through the foundset and delete the accounts based on the Accountname field.


                      To avoid people keeping WebDirect sessions open and to avoid people ending on your WebDirect homepage you can also supply a home url in the URL that will redirect people to a webpage of your choice after logging out. The confirmation script that runs based on the link could upon login automatically find the right record, set all fields you want to set and use the Exit Application script step in the end or on a 'Confirm' button on the lay-out. This will logout people nicely avoiding them from using concurrent connections longer than necessary.


                      I'm doing something very similar in one of our solutions. I have created a separate file to gather survey feedback using a UUID. I have a PHP page that gathers parameters such as UUID, local and action and builds target URL of a iframe in the same page. The script checks for the UUID, if it was already 'consumed' or does not exist it uses Exit Application to terminate the session and go to the URL supplied as the home URL parameter. Otherwise it will show a page with a few questions and a submit button. Using the PHP page is not a must, it just creates nicer URL's compared with a WebDirect URL that includes Home URL, Script and Variables.


                      The auto login works only on the separate survey file which has no sensitive information. Internally the results are linked back to our other data by using this table as External Data source. You will however need to make sure that all changes to the accounts (add, remove, passw change) in the main file are also maintained in the separate file. Since my solution is based on the data separation model already it did have routines in place already to handle the account changes.

                      • 8. Re: Creating a URL for a single record

                        I think we're very much on the same page (if you'll pardon the pun).


                        When an order is generated a temporary account would be created, the URL would be created by calculation and then sent via email. They login, authorise into a simple table (nothing sensitive) then log out. Once they Authorise the account is removed and if they don't authorise it is deleted after 15 or 20 minutes. If they need to authorise after it expires we'd have a script to generate a new temp login and URL.


                        We have PHP skills here so we could do it with an External data source (MySQL) and PHP but I've never done any of this with FMP.

                        • 9. Re: Creating a URL for a single record

                          trilogy1000 wrote:


                          We have PHP skills here so we could do it with an External data source (MySQL) and PHP but I've never done any of this with FMP.


                          Since you basically require to set only one field in one record each time, I imagine it is not too complicated doing this by CWP using the FM PHP API. But as mentioned before, I do not have any skills in that direction so I might be very wrong as well. It would certainly save you from the concurrent connection license that WebDirect would require.


                          You could also do it with a separate MySQL database for just the confirmation records and connect it to your FM solution as a external data source. Once you add a TO of this external data source to your relationship graph you can more or less treat is native FM data.