php with logon using FileMakers external account possible?

[Jalz]

Hi Guys,

I've got a database which has an external account, called allStaff. This external account is based on active directory and works with FM Clients as expected. I have added the php extended option to this account. My question, is, with PHP I want to connect to this account, authenticate that the user exists and redirect to a page. I know how to do this with a normal filemaker account with a username and password, but am interested to hear from anyone that has done it using active directory OR FileMakers external account.

Cheers

Jalz

[Genx]

It should just work.. authorize the same way you would with filemaker usernames, just prefix the domain.

e.g.

domainusername

password

instead of

username

password

You might wanna take a look at this if you wanna get SSO working: http://www.filemakerdesign.com/content/achieving-single-sign-filemaker-and-php

Edited October 14, 2010 by Guest

[Jalz]

Hi Alex,

Got my login manual external account login working by changing a couple of parameters in the connection file. The article on SSO was awesome, will definitely try and experiment with SSO. I've configured my IIS as per the article to see if would work.

If I setup the iis server as per your blogpost to allow integrated authentication, I've also altered my connection string below implementing the $_SERVER[‘LOGON_USER’] global variable to capture the username but what would I use to capture the password so FileMaker can compare it against my external account?

<?php

    $databaseName = 'CMS';

    $Lusername_AD = $_SESSION['AD_login'].$_SERVER['LOGON_USER'];

    $Lpassword_AD = $_SESSION['AD_login']['pass'];



    $AD = & new FileMaker();

    $AD->setProperty('database', $databaseName);

    $AD->setProperty('username', $Lusername_AD);

    $AD->setProperty('password', $Lpassword_AD);

Edited October 15, 2010 by Guest

[Genx]

Good question... don't actually know - will take a look when i can.

[Jalz]

Hi Genx,

Would definitely be interested in finding out if you figure it out.

Reading your article, my guess is that I create a user with the extended privilege set of fmphp, and within my connection string I actually store in the username and password.

Therefore if I've logged into the domain and go to the folder with the IIS permissions set as per your article, it should read my login and allow me to view the contents of that folder which will have the php pages to the open database. I think thats what your article suggests? If I am not logged in to the domain, windows asks me for my credentials and if they are correct it displays the content within the folders.

I would love to use the password (automatically like the username) though to create a secure environment in my connection string. Dont think that is possible without going into ldap territory?

[Genx]

Reading your article, my guess is that I create a user with the extended privilege set of fmphp, and within my connection string I actually store in the username and password.

That's the general idea, yes. To be honest I've never written a solution where it hasn't worked this way.

Therefore if I've logged into the domain and go to the folder with the IIS permissions set as per your article, it should read my login and allow me to view the contents of that folder which will have the php pages to the open database. I think thats what your article suggests? If I am not logged in to the domain, windows asks me for my credentials and if they are correct it displays the content within the folders.

Well if you want them to view the contents of a folder, i suppose... but normally you direct them straight to an initial page... e.g. send them to http://abc.com/index.php (or http://abc.com/ where index.php is a default page) we for example don't allow folder browsing at all... the less a user knows about the way something is structured, the better.

I would love to use the password (automatically like the username) though to create a secure environment in my connection string. Dont think that is possible without going into ldap territory?

I think the issue is getting confused here... LDAP will get you more information about the user from their username e.g. their email address, phone number, whatever the AD actually happens to store about them (with the exception of their password unless you've stored it using reversible encryption).

What you define as a secure environment however is what is boggling me. In short, if you want to rely on FileMaker security groups, i suppose you'd be interested in authenticating with the user's account each time here.. otherwise I don't really see a justification for it. Moreover - the portion of FileMaker security that is actually used by developers is simple (relatively speaking) to implement via basic PHP logic and in your interaction with the API...

Anyway, it's an interesting question but I guess coming from a SQL standpoint i can't understand the logic for wanting to authenticate the db connection itself with a different user account each time the user connects.

Edited October 25, 2010 by Guest

[Genx]

If you're interested in going into LDAP territory, this is the best class that i've found for that: http://sourceforge.net/projects/adldap

[Bryan VonDeylen]

I would like to know if you succeeded, and how.

I have been trying to create a login approach using the sample in the FileMaker Pro Advanced Lessons, but the Lessons do not get into external authentication.

Using the PHP Site Assistant gets authentication working, but it is too complex for me to alter to my needs. The Lessons are easier to understand. So I need to mix the two. Get external authentication working, but using code similar to the Lessons.

Would like to know if anyone else has succeeded and what the code looks like.

[Jalz]

Hi Bryan,

Yes I managed to get it to work. I used a product called FMSTudio (www.fmwebschool.com) to do it, but I don't think the product is being supported anymore. They've got their own forum on their website and also I believe a vide if I remember correctly - I did it a year or so ago.