Matt Klein

Members
  • Content count

    398
  • Joined

  • Last visited

  • Days Won

    1

Matt Klein last won the day on July 30 2013

Matt Klein had the most liked content!

Community Reputation

1 Neutral

About Matt Klein

  • Rank
    Certified Developer
  • Birthday

Profile Information

  • Gender
    Not Telling

FIleMaker Profile

  • FM Application
    14 Advanced
  • Platform
    Cross Platform
  • Skill Level
    Intermediate
  • Certification
    8
    11
  • Membership
    TechNet
    FileMaker Business Alliance
  1. Quick question....Is there a way to include a time stamp field in the WHERE clause, but check only the date and not the entire timestamp. In other words, ExecuteSQL("SELECT field1 from table1 WHERE timestamp_Created = ?"; ""; ""; Get(CurrentDate) ) I could do this with greater than or less than conditions in the WHERE clause. I'm just wondering if something like the sample query above can be done instead of the greater than or less than conditions.
  2. Just to keep everyone in the loop, I have confirmed that virtual WebDirect windows do NOT count against the concurrent connection limit.
  3. I believe that is the case. From the FileMaker WebDirect Guide: "When using third-party plug-ins with a FileMaker WebDirect solution, only use plug-ins that have been enabled for the WPE "
  4. Did you ever determine if virtual windows consume a concurrent connection? My guess is no because they are opened in the same browser window, but I don't like guessing on these types of things. Inquiring minds want to know!
  5. Greetings. I just returned from DevCon 2015. Wim, I really enjoyed your session on the Stand By server feature! So, I cornered the man responsible for the creation of and continuing management of WebDirect, Vin Addala, and asked him about the plug-in question I posed here. What he told me was that if you call the Install Plug-in File script step from WebDirect, the plug-ins will be installed in the appropriate location for use with WebDirect. In general, the Install Plug-In File script step acts on the context you are calling it from. So, calling it from Pro installs on the machine running Pro, calling it from Server Side Scripting installs in the appropriate location for the Server Side scripting engine, and calling from WebDirect installs in the appropriate location for WebDirect.
  6. I've done some research and have found that the Install Plug-in File script step will install plug-ins on the server via server side scripting. All the documentation I've seen states that it will install the plug-ins for the Scripting Engine part of server. I see nothing about the Web Engine part which supports plug-ins but the plug-ins are installed in a different location from the plug-ins for the Scripting Engine. Does anyone know if there is a way to install plug-ins for the Web Publishing Engine using Install Plug-In File script step or by some other means?
  7. I'm wondering if anyone knows if the plug-in API returns the script result when calling a script from a plug-in. I know you can pass parameters, but I'm wondering if you call a script with a plug-in and that script has an Exit Script[] step in it that includes a script result, does the API return that script result? I checked several plug-ins that have functions for calling scripts in FM databases and they don't include a function for getting the script result so I imagine the answer is no, but I thought I should ask the question before assuming. I have a long knowledge of using plug-ins, but the API is a mystery to me hence the question. Thanks
  8. Steven - So, is the following statement from the update notes merely a suggestion and not a requirement of the update?: "After applying this software, if you do not have a signed SSL certificate that matches your specific server name or DNS name, request a certificate from a trusted certificate authority (CA) supported by FileMaker, Inc." Thanks for your time
  9. I noticed that one of the updates in FMS13v2 is a fix for the Heartbleed bug(this actually was part of the 13v1a update too.) Am I reading correctly that you must get a custom certificate rather than use the FileMaker default certificate when if you use "Require Secure Connections"? I read this when 13v1a came out and thought I would sit on it for a little while to see what kind of conversations were going to happen. I haven't seen any really. Am I the only one concerned about this? It is my understanding that custom certificates are NOT inexpensive. Approaching clients that have FMS13v1 installed with "Require Secure Connections" turned on, and using the Filemaker default certificate to tell them that they now have to spend more money to get a custom certificate isn't all that appealing to me, mainly because it's not going to be appealing to them. What happens if we install the v2 updater and do not update to a custom certificate? Will FMS still work? Will workstations still see the server and function properly? I can't really test this on a client's computer and quite honestly testing it on our FMS server isn't a good business idea either since we have business critical apps running on it. I might be misinterpreting the documentation for the updater. I have to admit that SSL Certificates and how they work is not one of my strong points at the moment. Anyone? Feel free to move this to another topic. I just didn't see any other FMS13v2 threads and thought this would be a good place for it.
  10. mac

    Hmmmm....I did the same thing with my local server that uses the default FileMaker certificate and Get(ConnectionState) properly returned a "2". I am unable to test this at my client site which uses a custom certificate because their web developers added some re-directions to ensure that HTTP cannot be used.
  11. mac

    I've been doing quite a bit of research on this and talked to a FileMaker Engineer about it to get clarification. Having the "Require Secure Connections" box marked is NOT required for secure HTTPS WebDirect connections. The only thing you need to do to create the secure connection to WebDirect is use "HTTPS" in the URL. If you have FileMaker's default SSL certificate, you'll get the "annoying" message in the browser. If you have a custom SSL certificate, you won't get the message. This is the case because the "Require Secure Connections" box in the Server configuration effects the traffic passing between FileMaker Server and the clients(Pro, Go, WebDirect) not the traffic passing between the Web Server and the browser. WebDirect doesn't talk directly to the browsers. WebDirect talks to the Web Server which talks to the browser. So, it's the Web Server that handles the secure SSL connections via Browser. The only effect, that I've seen, that the "Require Secure Connections" box has on WebDirect connections is that, when it's marked, HTTP/non-secure connections cannot be made. Without the box marked, a user can use HTTP in the URL and access it without SSL. This I believe can be mitigated by using the Get(ConnectionState) function in the startup script and exiting the app if a non-secure connection is made. It is my understanding that if the "Require Secure Connections" box is not marked, traffic between Server, Pro, Go, and WebDirect is NOT encrypted/secure. So, No, your Pro/Go connections are not secure. All that said, I'm interested to know if you found a solution to your issue of not being able to access the databases with the "Require Secure Connections" box marked. I have run into that same problem and have not found a solution yet.
  12. 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?
  13. mac

    Hi Stephen - I'm getting ready to offer a WebDirect solution to my clients and we need to use SSL because of the industry we are in. I have the solution complete and tested it using FileMaker's standard SSL Certificate. I know that most of my clients will not want to be bothered with getting the "There is a problem with this website's security certificate." message every time they access the WebDirect app because the certificate isn't issued by a trusted authority. So, I'm going to need to recommend they get themselves a custom SSL certificate from one of the supported authorities. The majority of those clients will have a registered DNS name(ie. www.mywebsite.com), but they will not be hosting their own website. In other words, their DNS name will point to servers at their web hosting service. However, the WebDirect app will be running locally on their network so we would need to reference their static public IP address. I don't know anything about SSL Certificates and I've reviewed the FileMaker documentation and read through your post here. I'm still not clear on how to use the CERTIFICATE create command if the WebDirect app is running on their FileMaker Server. My question is, would they use the public IP address as the "server_name" in the CERTIFICATE create command or do they need to get a DNS name or am I totally off base here. Any help would be greatly appreciated.
  14. I'm pretty sure I know the answer to this question, but I have to ask because I'm really hoping I'm wrong..... Is there a way to change the current privilege set on the fly securely via scripting or some other method? I'd like to use FileMaker's security mechanism to prevent certain fields from being modified under certain conditions. I know that we can use the calculation engine when setting the Edit privilege under Record Privileges, but this effects the entire record and the calculation only evaluates when you "Open" the record. Ideally, we'd be able to use the calculation engine for the Field Access privilege, but we can't. Seems like the next best thing would be to be able to switch the current privilege set. I just can't seem to come up with a way to do this without exposing the password to the generic account setup that has the appropriate privilege set associated with it. The only way I know to do it would be to use the Re-Login script step, but putting the password in this step in a script leaves it exposed. Would it be any less exposed if it was stored in a custom function that was called in the password field of the Re-Login script? Would using FileMaker 13's ability to encrypt data at rest make it safe to store the password in a field now? I do use field validation, but I'd use it as a redundancy to the FileMaker security mechanism. Ever since FM7, field validation doesn't happen until the entire record is committed. From a user standpoint, this is less than ideal as they can enter a lot data before committing the record only to find out they can't do it. I suppose I could use script triggers, but that seems a little intrusive and leaves room for issues where I'd rather rely on FileMaker's security mechanism. Also, to replicate FileMaker's security mechanism's immediate dialog when attempting to edit a field, you'd have to set an onobject or onlayout modify script trigger which means the script would run for each keystroke which will add lag. I could keep going, but I'd like to hear what you all have to say about this.
  15. Hi All - I assume, correct me if I'm wrong, that the most secure use of FileMaker's security mechanism in a multi file app, other than using external authentication, is to maintain the accounts and passwords in all files in that multi file app. I'm just wondering how other developers are dealing with adding files to such an app that has been in place at a client site for a period of time. Are you hand entering the accounts in that new file with random passwords and using the Change Password script step to change the password for the accounts in each file? Are you making a clone of one of the existing files and freezing the all account activity on the app somehow until you have that new file done and running? Are you including empty files in your app for "future use"?