I was interested to read that FileMaker 16 now supports the ability to sign in with an HTTP POST.

I was wondering if anyone had tested this yet?

I'm looking at creating a custom login screen so any examples would be great. Thanks.

 

Are you using SSL? 

Yes

SSL will help keep the user name and password encrypted during transit.

It's basically a URL. Sent via an HTTP Post request. You include the user name and password as parameter as noted in the link you posted.

I know, but I was wondering if anyone's created an example.

Otherwise I'll just adjust our old IWP form.

Are you using a custom homepage? Or a completely separate web page that links back to the database?

Currently I'm using a permalink landing page which links to the database.

I'd like to change the landing page to a login page using the new HTTP Post functionality.

Sorry for all the questions. I ask them, because typically...if someone doesn't know how to send a HTTP POST call to a server, they also don't know how to secure that log in page. It would be easy to make that page, and leave the user name and password exposed for sniffing or tracking while being entered, and as it gets ready to send the POST request.

SSL helps you in transit, but there is more to it to make sure it's secure. A custom homepage may be a better option. Dress up the page the way you want, without having to manage the actual login to the database. Custom logins are great, for visual effect. However, they only maintain value, if you can keep the security solid. Often, the value to the user isn't worth the added effort and added risk. 

But you can still achieve much of the visual part with a custom homepage.

Interesting points.

Currently the landing page has optional SSL, however I can force SSL on that page to ensure the form is secure.

I'm taking it you haven't tried this new technique if you're concerned about the security of it?

It depends partially on the developers involved. I know the FM login process is secure. From there is usually about balancing the desire for something "custom". In every case I've been involved in, a customized version of the homepage was sufficient. The clients didn't want to spend the additional development time on something the "users only see for roughly 4 seconds". ( their words, not mine ). And in cases of single sign on, they may not see it at all.

So, the short answer is no, I haven't personally done it with a normal login process, like you are talking. I have used it to open a remote file to a guest login. Primarily because in the use-case we had, it was nearly impossible to not expose the user name and password without the use of an additional server.

You can redirect a user into a webd session with an html page with a little javascript like so...

<form id="myForm" action="https://your_host_name/fmi/webd/YourFile" method="post">
<input type="hidden" name="user" value="yourUser" />
<input type="hidden" name="pwd" value="yourPwd" />
</form>
<script type="text/javascript">
    document.getElementById('myForm').submit();
</script>

However, I would only use this to enable guest type access to a hosted file, and this is not really that secure, even if you have SSL enabled since the credentials are in the html. I have yet to find a way to redirect using POST, so for now, I would use with caution.

Mike

I've got some updates about this.

 

Creating a form works by using /fmi/webd/[DB Name] as the form action. Unfortunately it redirects to an invalid URL if an incorrect username/password are entered.

 

It's possible to customise the login dialog, by editing login.html in C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\jwpc-tomcat\fmi\VAADIN\launchcenter (or equivalent folder on Mac OS).

However if homeurl is used the generic VAADIN dialogue box is presented to the user.

 

Due to the issues with the custom login form I've gone with the second option for now.

The only way I was able to get the homeurl to correctly redirect me after a session was to include it as a GET parameters in the action attribute, but submit the form as POST. However, that only worked if you successfully logged into webd. If there was an error, it redirected to a malformed address. I will submit it as a bug.