One glaring feature still missing from FM13's WebDirect

[James Gill]

God, I hate to make the first post on these forums a whine post, especially since I have barely even installed FM13.

 

After I saw the WebDirect demo a couple of weeks ago, I was stoked to get my hands on FM13.  Well, today that day has come and we finally get to be hands-on with the new technology!  As I was watching the demo of WebDirect, I was struck by how amazing and game changing this technology was going to be in deploying Filemaker to the web for non-technical users.  Having tried to use Filemaker 12's IWP as a crutch for not knowing PHP, I am well versed in the limitations inherent to IWP when attempting to create custom solutions that mimic a web application's functionality.

 

One HUGE stumbling block of IWP was providing a custom themed login portal for our customers with a username and password field that was correctly masked.  In IWP, it was simply impossible to do this as there was no way to correctly mask password fields without some gimmicky trick like whiting out characters or relying on the user to click a button to activate a script.  Our company even tried to higher a large Filemaker consulting company to edit the backend code of Filemaker to manually set the field input type to a masked password, to no avail.

 

Imagine my shock then, when I boot up FM13 to see that there is still no option for masked password fields!  Granted, there are now ways around this limitation since field ScriptTriggers will now work with the web browser, but IMHO it's simply inexcusable for Filemaker to tout FM13 as having "Enhanced Security Features" when there is still no option to create a simple masked password field especially since it is now so easy to create interactive websites.

[xochi]

Could there be another way?  Does "Show Custom Dialog" perhaps now work in WebDirect and allow you to set the fields as Password style?  I don't have FM13 installed yet to test it.

[James Gill]

Could there be another way?  Does "Show Custom Dialog" perhaps now work in WebDirect and allow you to set the fields as Password style?  I don't have FM13 installed yet to test it.

 

There are definitely "other ways" to mask a password field in Filemaker.  The problem is that those alternative methods force us to design needlessly complex systems when the "Input Type" tag is native to HTML...

[xochi]

There are definitely "other ways" to mask a password field in Filemaker.  The problem is that those alternative methods force us to design needlessly complex systems when the "Input Type" tag is native to HTML...

 

But, if the "Show Custom Dialog" script step now works in WebDirect, and IF (a big IF) it also supports Password-style fields (and does it by properly using the HTML input type tag) then this might be a decent solution.   Not perfect, sure, but it would only require one tiny change to your layout:  Instead of having Username/Password fields on the layout, you just have a "Log In" button which pops up the Dialog box that has username/password fields.

 

James, are you at a workstation where you can test this out?  I don't have FMS13 installed just yet, but I'm dying to know the answer...

[James Gill]

I am currently installing FM13 onto a server setup.  I was originally running on an iMac but it was proving too slow to do what I wanted to do with it.

 

After reading through some unsupported features in WebDirect, I ran across this gem under their unsupported features section

 

 

 

• OnObjectKeystroke and OnLayoutKeystroke script triggers

 

There goes my idea of grabbing characters as they are entered into a field and masking them while storing them in a variable...

[James Gill]

I can confirm that Show Custom Dialog DOES work and it also does correctly pass the 'password' input type within the HTML code.  (That being said, I have to wonder how much overhead this 'auto-generated' CSS is adding to the web traffic come from the server....)

<input type="password" class="v-textfield v-widget v-has-width v-has-height" tabindex="0" style="height: 25px; width: 100%; background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAASCAYAAABSO15qAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH3QsPDigO/bwqsQAAAfNJREFUOMvNkz1ok2EQx3/39umHmpZWMUVaUEEUpWlQ0QyiCDooFhwcFN2lgqhTEMKTDwsZCw4SQQNOLh20KBgQRZ0kIK2LlBaqtNKhfkRqbHnfvOEc0kCbD0Enb/vD8bu7/93BfxfRaLTfWnuoqq21EWttqFm+s1ZYa692dHRMiUgWEEBEJCMiE/F4PN0IYGq0JyKbgJC19ryq+iKyH0BVZxoBpFbH4/HXInIUmFbVsojsBV6mUqkTTQGxWGy74zhdpVJpxRizw3GcnIi0rFYuA+dUdVFEAr7vf0mn05PrRjDG3ASG29vb6ytUQI9FKs0aY+4Bl2tNdP51a7Lq/kFV3aqqP0QkaIwZ/yvA2kgkEs9F5CQEiAydYbC/i6VPeR7l3uM1ALTU3MEFEYmKCJFLNzg1sA186NsVZl/nAvnp738+JGA34EOQPTs3UP6YY/T2KC8WymwJHaYHgABDw9c5G+6pB4yMjNzyPC8My/zyoKVvkEj4OAO9lUZbAdjI5t5ugp2tzY1JJpOavv9M55ZcVd9VV1XVndE3s8u6Plxtsr42jp0+QvfPCTJ3xvkKeHNT5J88IJsdY74M3yafksncrfuF6kvw9tUHDlyMcOVaBFbmeTj2jqIHxUIJF3A/z7K4WKhfY3WEaieBnjaKhWLTcX8DATq/EhizV6kAAAAASUVORK5CYII=); padding-right: 0px; background-attachment: scroll; cursor: auto; background-position: 100% 50%; background-repeat: no-repeat no-repeat;" autocomplete="off" keyev="true" clickev="true">

[Steven H. Blackwell]

I am not certain that I understand exactly what Mr. Gill was trying to accomplish.  

 

However, if the goal was to have a custom web page with a link to an IWP database that when the link was clicked a web page based forms authentication was presented with a true password field, that was easy to do in IWP and has been since at least FileMaker® Server 8.

 

FileMaker® WebDirect™ works a little differently.  However it too can present a dialog to accomplish this.

 

Steven

[James Gill]

I am not certain that I understand exactly what Mr. Gill was trying to accomplish.  

 

However, if the goal was to have a custom web page with a link to an IWP database that when the link was clicked a web page based forms authentication was presented with a true password field, that was easy to do in IWP and has been since at least FileMaker® Server 8.

 

FileMaker® WebDirect™ works a little differently.  However it too can present a dialog to accomplish this.

 

Steven

 

Yes, I know that there were ways to change the default landing page of IWP so that users were not presented with the default list of hosted databases on the Filemaker Server.  I also know that there are ways to pass embeded links with the path of the database you are trying to connect to.

 

What I want to do is bypass the Filemaker-based authentication process entirely and create my own authentication page.  Unfortunately, without a masked password field type (and without using a clunky dialog window) there's no way to do this.

[Steven H. Blackwell]

You can customize the authentication page.  However I strongly recommend that you do not try by-passing the authentication process.  Such systems are fraught with vulnerabilities that allow for escalation of privilege and unauthorized access.

 

Steven

[Reed]

The main reason I wanted a masked password field in IWP in the past was not to bypass the authentication process, but rather to allow the user to change their own password via IWP.  Of course it has been possible to do since 7 with a script step, but the password was shown in clear text while typing it.  If the show custom dialog will now work to do that, good deal.  Still waiting for my VLA email with my new links.....

[Steven H. Blackwell]

In the new WebDirect™ the ability for a user to change the password natively is present, similar to what one finds in FIleMaker Pro.

 

Steven

[milanm]

I think what James Gill is trying to accomplish is just a simple password masking field we are all familiar with, the one in which you type letters and numbers and it returns the *********** output. Am i right? In custom dialog you could choose this option but in the layout field you can not and with IWP you could not use custom dialog. I also installed FM Server 13 trial yesterday and having some issues regarding Web Direct which i will post in a separate thread...

[James Gill]

^

That is correct.  Don't get be wrong, WebDirect is lightyears ahead of IWP but having to prompt with a Dialog box to get a masked password field definitely smacks of "workaround" as opposed to something that, IMHO, should be a native field option in Filemaker.

[James Gill]

In the new WebDirect™ the ability for a user to change the password natively is present, similar to what one finds in FIleMaker Pro.

 

Steven

 

Steven, you're entirely correct of course.  I can certainly script password changes just the way that I've always done it within Filemaker Pro.  However, sometimes clients make requests that, on the surface, seem like a reasonable one and then one discovers that Filemaker requires a strange workaround.  In this case, I have no idea why Filemaker is missing a field type whose entry options would be 'masked' or 'password'.  It just seems like such a no-brainer that one questions why it wasn't included with FM13 in the first place.  What's even better is that obviously FileMaker did think of the need (Show Custom Dialog with Masked PW field) but hid it behind a clunky interface feature whose layout can't be changed to meet a clients demands.

On top of that, Filemaker 13's flagship feature is rendered almost worthless for those of us that require a custom login and/or landing page for our clients.  We're stuck using the default database login screen, which conveniently also doesn't include such common features as 'Forgot my Password' and 'Reset my Password'.

 

Unless I'm completely missing something, theres simply no way to make a standard, run of the mill login page with WebDirect.  If I'm wrong, please point of the errors of my ways.

[IdealData]

Allow guest access and take control with your own scripting after the automatic login.

[millennium]

So seven months in, does anyone have a best practices approach to doing what James and many clients want: a custom HTML login page?

[wbr]

I hear what James is saying, and I do find it frustrating that FM still does not offer any kind of character masking options on text field layout objects. I also understand why one would want to create a custom security solution entirely within Filemaker.

 

That said, I strongly agree with Steven that custom Filemaker-based authentication solutions should be avoided. I have 2 main reasons for this.

 

1. They are inherently insecure. A custom filemaker-based authentication system requires that your users are already logged into your Filemaker solution during the authentication process. This is not secure - no matter how tightly you tweak your security settings in FM.

 

2. The maintenance overhead far outweighs any benefits attained. I have built several solutions like this in the past. They work well and so far have not been breached (fingers crossed). However they are extremely fragile and prone to breakage. You will have to integrate the custom system with FM's built-in system, which adds multiple layers of complexity. You will have to be constantly vigilant that users & developers can't access login/account information. And for web based solutions, the complexity gets even worse. You will have to start tracking faux session IDs, logged-in status, and a number of other parameters. You're security solution will be at least as complex as the rest of the database solution.

 

So in the last 6 years or so, I've moved away from custom authentication in favor of simple, native FM authentication. And I'm confident that was a good decision. Our systems are now highly secure, and there is almost NO maintenance in keeping up the authentication parts of the database. It's also much easier integrating these solutions with external applications (web services, custom web applications, etc).

 

I would recommend using Filemaker's built-in security functions for FM client, IWP, and WebD solutions. For IWP, you can create a custom HTML home/login page, and pass login credentials to the IWP engine (use SSL/TLS!). I'm hoping there is similar functionality in WebD, but I'm happy to leave authentication management entirely to FM.

 

For custom web solutions based on Ruby, PHP, or any other language that accesses Filemaker thru the XML interface, you're on a different kind of playing field. All of your user interaction logic and functionality will be held in the web application, and Filemaker will simply be a backend datastore. Do not use Filemaker's built-in authentication to manage custom-web user access. That is a sure path to madness.