Permanent ID function (same as FileMaker Pro)
Moderator: Klaus
Permanent ID function (same as FileMaker Pro)
Hello from France to the Lc team
Excuse my bad english…
I use the FileMaker Pro function Get(PermamentID) to get an unique ID of the hardware, a very useful function to deploy and protect my databases and runtimes.
I've been searching for a similar function in Lc, without success.
I spent many time to retrieve the motherboard serial number using AppleScript shell script / VisualBasic, but i have no idea of how to get this data in iOS Androïd and Linux.
Is there an existing function to get this data, and if not, is this function planned in a future version of Lc ?
Thanks for your responses.
Best regards, Joan.
Excuse my bad english…
I use the FileMaker Pro function Get(PermamentID) to get an unique ID of the hardware, a very useful function to deploy and protect my databases and runtimes.
I've been searching for a similar function in Lc, without success.
I spent many time to retrieve the motherboard serial number using AppleScript shell script / VisualBasic, but i have no idea of how to get this data in iOS Androïd and Linux.
Is there an existing function to get this data, and if not, is this function planned in a future version of Lc ?
Thanks for your responses.
Best regards, Joan.
Re: Permanent ID function (same as FileMaker Pro)
Hi.
Not sure what you are looking for.
Do any of "the machine", "the processor" or "the platform" do what you need?
Craig
Not sure what you are looking for.
Do any of "the machine", "the processor" or "the platform" do what you need?
Craig
-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Permanent ID function (same as FileMaker Pro)
Apple works hard to prevent developers from obtaining things like motherboard IDs, for privacy reasons.
Most of us use a UUID generated on first-run. This may or may not solve what you need, if you have unusual usage patterns or extreme security absolutely requiring specific hardware IDs.
With a hardware-bound ID, what happens when the user upgrades their computer?
Most of us use a UUID generated on first-run. This may or may not solve what you need, if you have unusual usage patterns or extreme security absolutely requiring specific hardware IDs.
With a hardware-bound ID, what happens when the user upgrades their computer?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Permanent ID function (same as FileMaker Pro)
Are you sure you don't mean Get(PersistentID) ?
Craig, those wouldn't cover what ekami is looking to do, they are not looking for a generic description of the hardware they are running on, but a unique way to identify the hardware they are on.Get(PersistentID)
Purpose
Returns text representing a unique identifier of the computer or device running FileMaker.
Description
Returns a unique, unchanging identifier for the computer on which FileMaker Pro is running, the device on which FileMaker Go is running, or the current FileMaker WebDirect session in the form of a 32-digit hexadecimal string. Get(PersistentID) helps you identify devices that access your solution.
Notes
•
If web browser cookies are cleared during a FileMaker WebDirect session, the value returned by Get(PersistentID) changes.
•
If a FileMaker Go user restores an iOS backup to a different device, the value returned by Get(PersistentID) changes. If a backup is restored to the same iOS device, the returned value remains the same. For more information, see the FileMaker Knowledge Base.
•
For information on how functions evaluate differently on the host versus the client, search the FileMaker Knowledge Base available at http://help.filemaker.com.
Examples
For a FileMaker Pro client or a FileMaker Go client, Get (PersistentID) returns a value such as 78569d0bd40b898a64e7d08ccdea8220.
Unfortunately, there apparently *is* no way to do this in Lc based on the actual hardware of the machine, although Richmond and I sure put in the time trying to have it put in, and here is yet another good test case reason for it to be there.

-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Permanent ID function (same as FileMaker Pro)
There's a long discussion about this from a few years ago somewhere in the use-livecode list archives. I can't recall if the outcome was shell calls or maybe LC Builder IFF calls, but most of us lost interest once we considered the implications of motherboard upgrades, upgraded computers, etc.
I would be interested to learn more about the specifics of a scenario where hardware identification is truly needed.
I would be interested to learn more about the specifics of a scenario where hardware identification is truly needed.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Permanent ID function (same as FileMaker Pro)
Yes, which I linked too in the thread I linked too above in this threadFourthWorld wrote: ↑Fri Feb 21, 2020 10:57 pmThere's a long discussion about this from a few years ago somewhere in the use-livecode list archives.

No scheme is perfect indeed, is it, however, generating a unique ID from hardware is about as good as any other method I've heard of.FourthWorld wrote: ↑Fri Feb 21, 2020 10:57 pmmost of us lost interest once we considered the implications of motherboard upgrades, upgraded computers, etc.
You might never need it, I listed at least 3 cases where it would indeed be handy to have without learning the arcana of each of the 3 desktop platforms and 2 mobile platforms. The original thread had many more uses where it would be of value.FourthWorld wrote: ↑Fri Feb 21, 2020 10:57 pmI would be interested to learn more about the specifics of a scenario where hardware identification is truly needed.
However, the OP's question is answered, and as it is unlikely that it will ever be added to Lc, it is probably pointless to continue worrying about it.
Instead, if all the OP requires is a unique identifier, I would suggest possibly using 'the seconds' multiplied by a random number, which is likely to generate anything as unique as any other method I've heard of as well. Of course, if the base user has to reinstall his OS, which is probably more likely to occur sooner than changing out hardware, that method will not be able to rebuild the same id as using hardware would.
A motherboard doesn't generally die very often these days, after all.

-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Permanent ID function (same as FileMaker Pro)
LiveCode's UUID function does a good job of producing a standard UUID. Not hardware specific, but globally unique enough to serve most such purposes.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Livecode Opensource Backer
- Posts: 10080
- Joined: Fri Feb 19, 2010 10:17 am
Re: Permanent ID function (same as FileMaker Pro)
Despite all LiveCode's claims to be completely cross-platform we all know that is not true.
Now if one of my bits-n-bobs ends up on someone's computer in Bulawayo and the user wants
to, say, print out something from it, if the standalone can detect the hardware the OS is running on
that might facilitate things.
Just to give an awkward example: a client running MacOS 10.13 via a Hackintosh install on some
generic 64-bit something in the Philippines . . .
Can that imaginary client's copy of my standalone built for a Mac "just" do all the things it could do
on a real Mac?
Now if one of my bits-n-bobs ends up on someone's computer in Bulawayo and the user wants
to, say, print out something from it, if the standalone can detect the hardware the OS is running on
that might facilitate things.
Just to give an awkward example: a client running MacOS 10.13 via a Hackintosh install on some
generic 64-bit something in the Philippines . . .
Can that imaginary client's copy of my standalone built for a Mac "just" do all the things it could do
on a real Mac?
Re: Permanent ID function (same as FileMaker Pro)
UUID doesn't, as far as I can tell, give you any way to reproduce the unique result per machine, any more than using the seconds multiplied against a random number, you need a constant for that such as, oh, a MAC address.
For instance, if I create a loop such as
on my machine, the result is
On the other hand, this is incredibly easy to do using information about the hardware, but it is unlikely to be included in Lc. It is possible to get such information, but only if you have enough knowledge about each and every operating system your deploying too. For a language that is supposed to be 'easy' to use, I see this as a glaring omission, but I've already said as much previously.
Richmond popped in while I was composing the above, but -
For instance, if I create a loop such as
Code: Select all
repeat 5 times
put uuid() & cr after tVar
end repeat
put tVar
It is unique, but hardly what I would call 'persistent' , in other words, If my software were relying on this and was installed on a system, the system gets re-installed or for some other reason the software is removed (accidently, or as a step in trouble shooting), there is no way UUID will tell you if that software was ever on that system previously.78ff4b54-c997-4eab-8dad-d6e3ff57ec98
2e01a871-9660-4243-9265-d2af68dab0ec
06205ed4-f5c8-4ea2-83ef-37c7dd13c3c0
056676cd-e304-4186-a62a-a0fdc92782dc
0341c774-2304-4d19-b00f-0bc35527caa9
On the other hand, this is incredibly easy to do using information about the hardware, but it is unlikely to be included in Lc. It is possible to get such information, but only if you have enough knowledge about each and every operating system your deploying too. For a language that is supposed to be 'easy' to use, I see this as a glaring omission, but I've already said as much previously.
Richmond popped in while I was composing the above, but -
Not quite the same difficulty here, the OS is more than sufficient for printing. After all, if the printer isn't recognized by the OS, then the hypothetical user can't print anything else, so why would they expect to be able to print from your program?Now if one of my bits-n-bobs ends up on someone's computer in Bulawayo and the user wants
to, say, print out something from it, if the standalone can detect the hardware the OS is running on
that might facilitate things.
Yes, as the OS would have to be up and running in order for your program to start.Can that imaginary client's copy of my standalone built for a Mac "just" do all the things it could do
on a real Mac?

-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Permanent ID function (same as FileMaker Pro)
I'm not clear what printer compatibility on expressly-vendor-prohibited systems has to do with the OP's question.
I wonder if we might try to keep this support discussion on-topic, and wait for the OP to provide further guidance on how we might best serve the goal of this thread.
Other topics are of course welcome here, in a separate thread devoted to them.
I wonder if we might try to keep this support discussion on-topic, and wait for the OP to provide further guidance on how we might best serve the goal of this thread.
Other topics are of course welcome here, in a separate thread devoted to them.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Permanent ID function (same as FileMaker Pro)
Hi,
about the Filemaker function. From here:
From here (scroll down, last post):
It now depends what you want to do with your program - nail it down to a certain machine & configuration, and have support calls coming in every time something changes on this machine? IMHO not the smartest idea. A quite interesting article & discussion about the Win version is here.
There's some issues to regard for "locking down" programs:
Have fun!
about the Filemaker function. From here:
Looks really useful, right?
- If web browser cookies are cleared during a FileMaker WebDirect session, the value returned by Get(PersistentID) changes.
- If a FileMaker Go user restores an iOS backup to a different device, the value returned by Get(PersistentID) changes. If a backup is restored to the same iOS device, the returned value remains the same.
From here (scroll down, last post):
Dunno about changing MACs on iOS, but the desktop versions should just require a:On an iOS device, Get (PersistentID) will return the MD5 hash value of the Mac address of the device.
On Macs, Get (PersistentID) returns the MD5 hash value of the Hardware UUID as seen from "About this Mac -> More Info -> System Report -> Hardware"
On Windows, Get (PersistentID) returns the MD5 hash value of the UUID when you type the command line:
wmic path win32_computersystemproduct get uuid
Code: Select all
if the platForm begins with "mac" then
put "aSuitableMacShellCommand" into myShell
else if the platForm begins with "win" then
put "wmic path win32_computersystemproduct get uuid" into myShell
else exit to top
put md5digest(shell(myshell)
There's some issues to regard for "locking down" programs:
- IPs & MACs are not reliable. Both can be changed, and both can change in perfectly innocent ways - NAT, dynamic IPs, VPNs, docking stations, tethering etc.
- There are perfectly legit situations where the hardware/ system software may not be the same every time - virtualization, containers, different machines, restores etc.
- A user that gets "access denied" in a situation that's legit in his view is a very angry user. Murphy dictates that such cases always occur when the user a.) really is legit, and b.) needs to use your program for something really important.
Have fun!
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
Re: Permanent ID function (same as FileMaker Pro)
I was waiting as Richard suggested for the OP to pop back in, but part of your post really intrigues me AxWald, and that is that it was as I suspected, persistent ID is geared from all appearances to be generated from the hardware of the system, and is repeatable.
While the information presented following it I have no disagreement with, how many people do you suspect regularly go about altering their hardware reporting? You, Richard, and I might do so fairly regularly, but Joe Average? Not the ones I've met, and it seems as good a way to tie off as any other scheme I've seen. Good enough for MS to have employed it, anyway.
While the information presented following it I have no disagreement with, how many people do you suspect regularly go about altering their hardware reporting? You, Richard, and I might do so fairly regularly, but Joe Average? Not the ones I've met, and it seems as good a way to tie off as any other scheme I've seen. Good enough for MS to have employed it, anyway.
Again, how often do you suspect average people are changing out hardware in their systems? OS re-installs shouldn't affect the way the hash works, so even a complete replacement of the OS wouldn't alter the ID generated under the description given.

-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Permanent ID function (same as FileMaker Pro)
Thank you for that background, AxWald. Very relevant here to learn the specifics of FMP's implementation.
The OP suggested obtaining the motherboard ID, apparently that's not what FMP is using, given this from Claris' documentation:
https://en.wikipedia.org/wiki/Universal ... identifier
As we see from Claris' own description, UUID can reasonably be assumed to be unique, but it's a misnomer to call the function "permanent" or even "persistent".
True, most end-users don't replace their motherboards much these days, but even if we set aside AxWald's prudent reminder of how Murphy's Law applies to deploying software systems, and also ignore the relative ease of spoofing MAC addresses, a UUID derived from the MAC address each time it's used is inherently problematic if one requires permanence:
What happens when the user walks outside of their wifi range?
A phone does indeed have a MAC address, but for wifi only. Cellular connections use a very different mechanism, dynamically assigning a MAC address which is subject to change.
So while we all recognize the value of having a unique ID, a truly permanent ID is a non-trivial problem to pursue, one that apparently not even FileMaker attempts.
There are various ways to create a globally-unique ID, but since LC has an RFC-4122-based function built in why not just use that?
When called with no arguments, it generates a random UUID - unique, but not persistent.
However it can be called with args specifying both hash type and namespace with an arbitrary string ID, and passing in consistent inputs will produce consistent outputs.
But since the namespace arg itself is already a UUID which must be stored some place to be able to pass it in each time the UUID function is called, unless you have a specific need for namespaces you could just as easily call UUID with no params once and store that value for use when such an ID is needed, as I'd suggested earlier.
The OP suggested obtaining the motherboard ID, apparently that's not what FMP is using, given this from Claris' documentation:
It's likely FMP uses the RFC 4122 UUID standard, which is what LiveCode uses for its built-in UUID function:Notes
•If web browser cookies are cleared during a FileMaker WebDirect session, the value returned by Get(PersistentID) changes.
•If a FileMaker Go user restores an iOS backup to a different device, the value returned by Get(PersistentID) changes. If a backup is restored to the same iOS device, the returned value remains the same. For more information, see the FileMaker Knowledge Base.
https://en.wikipedia.org/wiki/Universal ... identifier
As we see from Claris' own description, UUID can reasonably be assumed to be unique, but it's a misnomer to call the function "permanent" or even "persistent".
True, most end-users don't replace their motherboards much these days, but even if we set aside AxWald's prudent reminder of how Murphy's Law applies to deploying software systems, and also ignore the relative ease of spoofing MAC addresses, a UUID derived from the MAC address each time it's used is inherently problematic if one requires permanence:
What happens when the user walks outside of their wifi range?
A phone does indeed have a MAC address, but for wifi only. Cellular connections use a very different mechanism, dynamically assigning a MAC address which is subject to change.
So while we all recognize the value of having a unique ID, a truly permanent ID is a non-trivial problem to pursue, one that apparently not even FileMaker attempts.
There are various ways to create a globally-unique ID, but since LC has an RFC-4122-based function built in why not just use that?
When called with no arguments, it generates a random UUID - unique, but not persistent.
However it can be called with args specifying both hash type and namespace with an arbitrary string ID, and passing in consistent inputs will produce consistent outputs.
But since the namespace arg itself is already a UUID which must be stored some place to be able to pass it in each time the UUID function is called, unless you have a specific need for namespaces you could just as easily call UUID with no params once and store that value for use when such an ID is needed, as I'd suggested earlier.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Permanent ID function (same as FileMaker Pro)
I'm curious how you arrived at that conclusion from those notes? Skipping the WebDirect part of it, which is obviously based on a cookie, the rest seems to say exactly that it is using a hardware ID to create the hash.FourthWorld wrote: ↑Sun Feb 23, 2020 5:00 pmThe OP suggested obtaining the motherboard ID, apparently that's not what FMP is using, given this from Claris' documentation
As far as the 'relative ease' of spoofing a machine access code goes, I'd again suggest that it isn't very likely for the average person. In this area I feel relatively confident that I've had sufficient experience to say that just getting the average user to renew an ip address is almost beyond their abilities, never mind their being up to spoofing unique hardware codes being read from the local machines OS.FourthWorld wrote: ↑Sun Feb 23, 2020 5:00 pm•If a FileMaker Go user restores an iOS backup to a different device, the value returned by Get(PersistentID) changes. If a backup is restored to the same iOS device, the returned value remains the same.
Not sure what this -
or this -What happens when the user walks outside of their wifi range?
has to do with anything. You seem intent on Network cards mac addresses, ok, we'll swing with those, the MAC on a network card doesn't change because you are on another network, nor does it disappear when you make a phone call, and even if it somehow did, what that has to do with a software application is beyond my ability to ken.A phone does indeed have a MAC address, but for wifi only.
How is that going to come close toyou could just as easily call UUID with no params once and store that value for use when such an ID is needed, as I'd suggested earlier.
if the device has to blow your software out, or be completely re-installed either from scratch or a backup where your software didn't exist, you sure can't store it on the device itself. Server is out too, unless you have some way to determine that it is the same device.a backup is restored to the same iOS device, the returned value remains the same.

-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Permanent ID function (same as FileMaker Pro)
The operative clause is "a backup is restored".bogs wrote: ↑Sun Feb 23, 2020 5:56 pmHow is that going to come close toyou could just as easily call UUID with no params once and store that value for use when such an ID is needed, as I'd suggested earlier.if the device has to blow your software out, or be completely re-installed either from scratch or a backup where your software didn't exist, you sure can't store it on the device itself. Server is out too, unless you have some way to determine that it is the same device.a backup is restored to the same iOS device, the returned value remains the same.
No backup, no dice.
If you truly must have a motherboard-ID-based UUID-like ID, go for it.
But that doesn't seem to be what FMP uses, Apple's dev docs describe how hard they try to make obtaining that for mobile apps, and it just isn't how this problem is most commonly solved.
Lots of devs need globally-unique IDs. Very few are motherboard-ID-based. Most use RFC 4122 UUIDs. And that's built into LC, so it seems a good fit, allowing the developer to move on to more interesting problems.
All that said, the OP hasn't describe the use-case for which this is needed. I recognize that it just might be every bit as uncommon as the request that the ID be specifically motherboard-based. We simply don't know yet, though I look forward to learning more about that, and how the limitations FMP described for its own implementation weren't a problem for that specific use-case while LC's RFC 4122-based UUID is presumed to be a non-starter.
In fact, Joan hasn't returned since the original post. Everything written after that beyond a handful of questions for Joan is based solely on conjecture about the true requirements of the use case. We'll see how it pans out when Joan returns.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn