NO, it is NOT persistent. It only persists for the duration of the cookie. Due to sandboxing of browser clients, FMI can't establish a persistent ID based on hardware.
I have a sample on my blog about an auto-login script that may help display the limitations.
I have played around with browser fingerprinting as an alternative to PersistentID as well but eliminated it due to the information changing all the time (browser updates changing the agent string), and the potential vulnerability to spoof/MITM attacks.
That said, the best you can do natively is use the PersistentID and require the user to re-login if that PersistentID changes.
Or if you used the PHP passing method, you could create your own cookie that may persist longer and pass the UUID into FileMaker
(see this blog for sample code: Enabling WebDirect URL parameters | MainSpring )
And to add, The cookie that contains the UUID identifies itself as a "session" cookie, meaning it expires when the session expires (not the filemaker session), I have seen this persist as long as five days in the past, but I haven't checked to see if it was changed in FMS14.
Thanks for the information. I used your Blog and a few other sources to fashion my own two-factor ID system. But forcing the WebD users to reauthenticate so frequently is getting me flack. Trying to find something that will last a little longer. It would be nice if we could get the NIC Id through WebDirect as well as the public IP they are running through. I would even like to go so far as issuing my own "security key" file, but I'm not sure how to make that available in WebDirect in a convenient manner. Add the problems with File downloads, and things have been a tad frustrating of late. Improvements are always in the making. ;-)
If you can do it in PHP, then you can pass the authentication from PHP into webdirect via the second link I posted to. As I noted I was experimenting with browser fingerprinting, there's also evercookie, which attempts to make an extremely persistent cookie.
So in essence, if you went one of those two routes to try and get a more persistent ID, the process would be:
1) Create PHP script that generates that persistent cookie for the user, and begins a PHP session to store that UUID, then on subsequent visits reads the cookie or recreates if extinct.
2) Create a redirect on the tail of that PHP script that then redirects to your WebDirect file.
3) WebDirect auto-logins using the lowest security privilege possible.
4) OnEntry script uses a webviewer or insert from url scrape to get PHP session variables.
5) UUID is checked against known "good" UUIDs.
6) Relogin/escalation is performed if UUID is matched. If no match, user is challenged with relogin, and UUID is stored as known "good" UUID.
7) proceed as normal.
I would also write a server scheduled script to check for "orphaned" UUIDs in filemaker and trigger an alert if a certain threshold per x amount of time is reached. This way you can detect proactively if someone is trying to maliciously access it with random UUIDs and not logging in during step 6.
My second blog post I linked to provides most of what you need for that. However in addition for step 1 you'll have to write the language that checks and generates that UUID. If you need help on that let me know and I might be able to work something out to help you.
The PHP stuff sound like it may work, but is overly complicated. I hope FMI will come up with something a little better down the pike. Thank you for your assistance.
Wow Mike... head about exploded. I am reading slowly....and thats pretty Awesome!!! + 1 for that one!
There's still not a good easy solution for WebDirect.