--------------------------------------------------------------------------------We don't use the IP address for anything of significance. It's just there for your use. We take a "fingerprint" of the hardware to uniquely identify computers. See: How hardware-locked licensing works.--------------------------------------------------------------------------------Certainly; I appreciate the link but it's not exactly what I was trying to explain. Let me be more clear.
I understand the authorization server will create effectively a 'fingerprint' of the system that when joined with the serial will active that specific system.
Our current issue is that this process is mostly anonymous. I'll explain below why we need more information (or the ability to track information for each authorization).
--------------------------------------------------------------------------------Additionally, we think we could give our purchaser more information abouthis 'authorized seats' if features we're not only associated at the 'pkey instancelevel' but at the 'seat level' as well. Is this a 'feature request' (or an analogousmechanism) that is planned or realistically able to be done?I'm not quite sure I understand. You want to have or set specific information abouteach computer? Why would you need or want that? What could it be used for?--------------------------------------------------------------------------------Take the use-case of an organization purchasing 250 licenses for a product we offer. Using LimeLM we will be given 1 key which represents that purchase with 250 seats effectively.
As the key is given to the staff and they authorize their version the seats decrements (let's say we're at 230 out of 250 seats remaining).
A single member of staff (call him Mr.Bob) gets their computer stolen, lost, is fired, etc. and the organization would naturally like that seat to be re-added to the pool of seats (so if that was to happen we would be at 231 seats).
As far as I can tell now we have an issue. I go to LimeLM and must answer the question 'who is Mr.Bob?' so I can revoke his seat. However all I see a list of all the 'authorized seats' with their OS and ip address (I assume the ip address is logged whenever the last authorization occurred).
We have several options:1) Treat each member of staff as a purchaser. This would entail modifying the workflow so that each member of staff gets their own key and use 'features' to associate them to an organization (something like feature['organization_title']).2) Manually keep track of ip addresses and associate them to additional data like name (so I can match Mr.Bob to his ip address).3) If there was a mechanism to track data per seat I could associate the 'seat' of Mr.Bob to an additional data field (like a name). Or, if there is additional data that allows us to identify more information about the 'seat' perhaps we could associate it to Mr.Bob as well
1 causes us to modify our workflow and potentially mangle the common workflow defined by LimeLM. However it appears workable.2 isn't acceptable for a variety of reasons3 not sure if there is that capability
