filemaker db api for php connection

[Mark Johnson]

Im looking at creating a connection class for connecting to the different databases that ill be needing to connect to to query for data and not familiar with classes much but found this one im trying to figure out.

 

How do i get it to work properly and return to me what i need and also that it did connect successfully? as well as being able to use it for other filemaker databases i need to connect to?

 

 

The connection details below is example but ill connect to logins.fmp12 first to check the users credentials with a table that has their login and password info then if success and they are active then ill go to a layout where they can do finds and pull data for customers etc which will not be the logins.fmp12 database it will be something like ohc_data.fmp12?

 

 

 

 

 

<?php

 

require_once 'FileMaker.php';

 

 

class FilemakerDB {

// database connection details

public static $host = '192.168.1.10';

public static $database = 'logins';

public static $username = 'user';

public static $password = 'pass';

 

private static $connection  = null;

 

// Private constructor for singleton pattern

private function __construct() {

}

 

/** Values required for setting up the connection. **/

public static function setup($host, $database, $username, $password) {

self::$host = $host;

self::$database = $database;

self::$username = $username;

self::$password = $password;

}

 

// filemaker database connection

public static function getConnection() {

if (!self::$connection)

{

self::$connection = new FileMaker();

self::$connection->setProperty('database', self::$database);

self::$connection->setProperty('hostspec', self::$host);

self::$connection->setProperty('username', self::$username);

self::$connection->setProperty('password', self::$password);

 

}

return self::$connection;

}

 

// clone private for singleton pattern

private function __clone(){

}

}

 

$db = new FilemakerDB();

 

if (FileMaker::isError($db){

    echo "Error";

}else{

    echo "Good Job";

}

 

 

?>

[doughemi]

Well, first off, a table of usernames and passwords is a Bad Thing. It is a terrible security hole. It is much safer to use FileMaker's Accounts functions to access any database. Set up an account for each user.  There are FileMaker script steps to create, enable, disable, and delete user accounts which can be used in scripts accessible only by an administrator.

 

Secondly, why have multiple files?  After logging in to a database using the FileMaker API and native FM tools, your user is automatically given access to whatever tables his Privileges allow. Any number of tables can be contained within one file.  FileMaker Privileges can restrict access to tables, fields, and/or layouts.

 

Building new classes is just duplicating the functions already included in the API. 

 

It is simple to check for a connection:

# instantiate a new FileMaker object
$fm = new FileMaker($fm_file, FM_HOST, $fm_user, $fm_pass);
//
//  The following code checks that we are connected to the database
//  and if we are not, displays a message.  
//
$accessed = $fm->listLayouts();
if(FileMaker::isError($accessed)){
Header("location:http://YourHost/No_DB.php");// an html page that displays a "no connection" error message
exit;
}
//The rest of your php code here

Can you provide a more concrete explanation of the business model?

[Mark Johnson]

Well the reasoning with the table of logins is its not for internal use its for a client website for our clients to login and we arent talking just a few, were talking about a few 1000 or more. Now granite we only have about 5 or so logging in at any given moment. 

 

Right now we have a .fmp12 file that is slated for IWP in filemaker 12 that is in general just a portal meaning it only has 1 table but references all our other filemaker files via relationships. the reason why its multiple files is this is a database that has been built and added on since filemaker 5 and im the one dealing with it now. I would like to have a data seperation model where we have a data file and interface file but that would be an EXTREMELY long project and almost impossible for us to do in a good time frame plus to make sure the data is correct.

 

Theres alot of stuff that was done really funky and not by far the best way but to go and change that to a more effective way or less calculations or less scripts and all that would be hard.

 

***********************************

 

- Now for logins issue......

 

Right now we have a client record with a corporate login (all records assigned to that corporation), regional login (only records assigned to that region) and client login (the individual location only meaning that 1 location). Now we do have a table for contacts where we can assign multiple contact people tot hat one location but if that one person is part of other client records then you have to add them to those client records as well. What i would like to do is be able to assign that one person to multiple client records across the board but thats a different story i guess possibly.

 

As for the function, how would i put that into a class or just a function to pass different logins if needed and return what is needed to say it was good or what would i return in the function for that? And how would i use it on the php code if i wanted to pull a list of client records once the function passed and it connected? Im trying to learn functions and some of it i can udnerstand but not when it comes to classes or writing functions for filemaker API for php. that im still learning but i need to learn it.

[doughemi]

I have a solution that has over 3500 accounts (nearly 2500 of them active) with a similar limited number of simultaneous access requests. I use FM Accounts for logging them in with no problems.  Granted, the initial setup of accounts in each of the files in a multi-file solution will be time-consuming, so it may behoove you to consider using the time to gather all the files into separate tables in one file instead. 

 

A good way to look at the login problem is to define roles.  Each role would have its own set of permissions (e.g., for corporate, regional, or client).  You can then assign each role its own privilege set.  Privilege sets can define viewing privileges conditionally, so you could then create conditional calculations for viewing or writing access to records for the outliers.  Or, depending on the number of different combinations of conditions within each role, you could create privilege sets for the various sub-roles. You can then assign each user account the appropriate role. In other words, incorporate the logic of your password table into the more secure FileMaker native Privileges structure.

 

I'm afraid I still don't understand why you feel you need a php function definition for login, since it is a one-time operation.  Save the $_POST['username'] and $_POST['password'] data in $_SESSION[] variables, open the connection to the first database file with a new FileMaker() call, and open the other files as required with additional new FileMaker() calls (assigning them to different variables, of course).  The subsequent files required could be calculated and set in a field in the opener file, and passed to the php with a getField() call.

[Mark Johnson]

Well as for moving all the files into separate tables or one solution that would be next to impossible. Not Impossible but next to. It would be extremely time consuming. Its been added to by so  many people that its just gotten out of hand but to go and do all that into one solution and all wouldnt be very good. Its all to intertwined together plus we have c# apps that connect to the different solutions that would have to be re programmed to accommodate it.

 

The only reason i was gonna put them into a function is to not use something that can be put into a function if that code is being used all the time but considering its only used once i guess, it doesnt matter. The whole APi for PHP thing is new to me as well as php also so im learning as i go hands on.

 

I dont mind using the filemaker native security login stuff and i can get it all set up that way no problem but it will be time consuming but we may potentially have like 10000-20000 users as right now we have 14000 clients but not all of them have website access but going php we will be working on moving alot of them toward using our website. We dont do it much now cause we are using iwp and to us it just sucks all around.

 

The other thing i can do is use one file that has external connections to other files and just have layouts for the different solutions in one file referencing that file. So basically like a data separation model would be, you have an interface file that everyone uses but it references the data file. A file thats like a portal to other solutions if thats able to be done. So they login and check the login with that one file and then i can query tables form other solutions in that one file just going to the layout assigned to it.

[webko]

OK, I'll have a stab at this... Given that I've got a system that has c20K unique users, and only one FileMaker native account for them... And they actually have different levels of access in the system.

 

It is worth remembering that the account details they use to login do not have to be the same as any FileMaker account.

 

So, I use a table of web only users - and then make the PHP application only use the 'web_access' FileMaker account, which has the various attributes set for XML access (as I use FX.php rather than the API)

 

Any login is checked via the web_access account to the WebUser table to find a match - if so, I can then set some session variables to control their user experience elsewhere in the PHP application.

 

The advantage for me is that I do NO user administration, ever - it's all in the web application - create new users, confirm them, change passwords, reset details, allow administrators to deactivate them, have their account automatically deactivate after x months of no use etc etc.

 

Also, if you replicate the one web_access account through the various files, you can view the data over relationships from their main table - I'd hate to have to replicate x000 users across multiple files....

 

Hope this helps

[soulicious]

 

So, I use a table of web only users - and then make the PHP application only use the 'web_access' FileMaker account, which has the various attributes set for XML access (as I use FX.php rather than the API)

 

Any login is checked via the web_access account to the WebUser table to find a match - if so, I can then set some session variables to control their user experience elsewhere in the PHP application.

Hi Webko,

I'm struggling with a problem that it seems you have solved in the past (based on the quote above).  May I bother you for a few details about how you do it?

I have a PHP (PHP API) web interface using a table-based login that I need to set the security in such a way that the current active user can only see their own records.  This is simple if I used an "Account Based" login, but since my database will have many users, I went with a table based login for ease in management.

The problem then, is that the Get(AccountName) always return the "web_Access" account.  I can't wrap my head around how you use the web_access account to match a user in the WebUser table which then can be used for setting the privilege set criteria.

I haven't been able to come up with a way to say: if the user is "web_access", then make the web_access = ActualActiveUser.  Then I could use this info to limit viewing within the privilege set by limiting record viewing to ActualActiveUser = RecordOwner.  It sounds like you are using something on the PHP side to help with the logic..?

Any help is greatly appreciated!

 

 

[webko]

Yes, it's the PHP that controls this...

Let's say I have user 'Tim Booth' in the table, and I successfully login... At that point I would set

$_SESSION['user_name'] = "Tim Booth";

On any subsequent search, I also use that session variable, against the RecordOwner field for that table... So it becomes part of every search, rather than part of the Account Privileges.

Hope this helps

Webko

 

[soulicious]

Much appreciated, Webko.  Thank you!