I don't think that there's anything wrong with authenticating a CWP/PHP-based app using FileMaker accounts. However, my preference has always been to build my own authentication and user management into the Web app.
One big reason that I prefer to do it that way is that I typically need to know more about a user than just their account name and privilege set. For example, in many cases, I need to know a user's first and last name, organization / department, email address, etc. Also, I want to give them an easy way to handle self-service tasks like resetting passwords and so on - and it seems to me to be easier to do that with a custom authentication / user management function.
I hope this helps or at least gives you a few things to think about. If you have any questions about how I handle this, let me know.
Thank you for your reply.
I work for a very big school system (200 + schools and another 60 or so locations of other types) and we use FileMaker in almost every location and from time to time need to do a variety of thing with FM via the web. Like many places we stared with CDML and did a lot with FileMaker on the web and then with the advent of FM 7and the loss of CDML we toyed some with Lasso and eventually did less and less via the web until FM 9 and the arrival of the Site Assistant. With the Site assistant we began to be aggressive web users once again. We are a 99% windows system and use Active Directory for everything - where it make sense to do.
Now that we no longer have the Site Assistant and although I learned significant PHP leaning how to "hack" the pages created by the Site Assistant I am now [sans the SA] in the position of wanting to learn to code my FM-PHP pages on my own.
I am now working my way though a couple of books (J stark and T. Duell) and have been studying the FM 13 API example scripts and then looking closely at the scripts generate by the FM 11 Site assistant. In doing this I notice how the SA generated scripts, universally, use CGI to handle the Authentication business and like how that plays nicely with Active Directory.
I have done what you suggest from time to time - when that made sense - because of the application's requirements. However, in my recent studies I noticed that none of those writing about how to do FM-PHP even mentioned, much less discussed the CGI approach and so I was curious why.
As I look at the pages generated by the FM 11 Site Assistant I see that there seems to be a lot of code generated to make the CGI "work"; in fact, there seems to be one long script page "fmview.php" that is generated to allow th CGI to do its work.
Maybe the answer is that it is just too complex a task - for the benefits derrived!
Side note: I often make it to Richmond to vist my grand children.
Interesting! I have a client that is similar to what you described - a school district here in Virginia with thousands of users spread out among a number of schools, warehouses, admin offices, etc. They are a big FileMaker shop, and use it to supplement their student info system. FileMaker has been a big success for them, especially Go running on iPads. Oddly, they've never really expressed interest in custom Web published solutions.
Based on what you described, it sounds like getting the API to "play nicely" with Active Directory is important. It would be inconvenient for users to have a single sign-on for everything except for your Web solution.
I have another client here in Richmond (one of the colleges) that uses CWP-based apps with Open Directory, and that has been a success for them. Essentially, we authenticate against FM, which in turn authenticates against OD. We store the account name / pw in session state, and are very careful about timing it out and forcing session resets for idle users. I'm wondering if you couldn't use the same approach with AD. Anyway, if you want to chat about that at some point, let me know.
On another note, you might want to take a look at FMWebFrame. It's an open source extension to the FileMaker API for PHP. It might help you to learn more about the API and PHP in general. Details are here: http://fmwebframe.com (I will be releaisng a new version of FMWF in a few weeks.)
Tim, again, thanks for the quick reply.
I will most definitely look at your extensions for FM-PHP.
Where we currently use the web big time is when we need users to be able reach data and/or do some work with data that happens to "resides" in FileMaker is when we need users to be able to access that asset outside of the firewall without having to do the whole VPN dance and worry that the users laptop, etc. is not correctly configured, etc.,etc.
This is a case where the browser is our best friend!
We have done a ton of stuff also with IWP and are a bit anxious about how Web Direct is going to work as the new "instant web publishing". In many of these applications (IWP) we have used table views extensively. Now, it looks like we are going to have be much more creative developers as we look for ways to offer list views that do for us what the old table views were able to do!
The additional plus for us is that web pages work on all brands of tablets - so when decisions - above my pay grade - are made about tablet purchases then I do not have to worry so much.
There are big advantages and big disadvantages about being a 99% Windows world!
Next time I get to Richmond I will try to call and buy you a cup of coffee...
I think what you've come up against is that the Site Assistant generates "Object Oriented" code, which is much more abstracted (among other things) than the "procedural" code most often taught in beginning FM/PHP books/courses.
It is absolutely possible to authenticate a web user via FM Security (whether External Authentication/AD or internal FM accounts) using procedural code -- without any need for a "CGI" PHP 'class'. So the other ways you've read about authenticating users should be absolutely fine. It's a matter of programming style (OO vs procedural), not a matter of FM authentication.
FWIW: It's pretty commonly believed that examining code generated by the Site Assistant is not a very helpful way to learn how to work with the FileMaker API on your own
Thank you for for the added information.
It helps the motivation to know that I can get where I want/need to go without the CGI thing.
I have to agree, that in this case, examining the code seems to raise more questions than answers.
It is an old habit I picked up when I was first learning CDML before the arrival of the Claris tool and some times that habit stands me in good stead and other times it just leads me down dead-end roads.
It's like the cliche says, "Often, time spent trying to reinvent the wheel is ...just time spent!