masseyfAny ideas?? Is it possible at all? My time for developing this is running short...
Thanks!
Get VersionID based only on PK
masseyfHi Wyatt,
I'm trying to implement the "limited update" according to the example provided as part of the web API package. But the example is limited to one product (i.e. uses a specific Version ID). In our case, we have dozens of products so we don't know to which product the PK passed on the query string belongs to. Now, to get the information related to a product key you need the Version ID. All PK-related calls in the API necessitate the Version ID except for AdvancedSearch, which, I believe, now returns the Version ID. Unless mistaken, I saw no way to limit the advanced search to return information for a single pk (as does the Find call, where a pk can be set in place of the email to return a single pk). The advanced search returns potentially very large datasets that would need to be parsed to find the product key. That is too intensive a task to be used in a web server context, particularly because we have so many PKs.
Is there any way to discover the Version ID based SOLELY on the product key?
Sorry, yes, we're looking about just removing the requirement for the version ID altogether for the limelm.pkey.getID function, which would solve your problem.
masseyfThat sounds great. May I ask for an ETA?
In the meantime, short of maintaining our own database of PK (or parsing the lot from an advanced search) there would be no workaround?
Thanks, as always!
That sounds great. May I ask for an ETA?
Yep, we just changed it. limelm.pkey.getID no longer requires a version ID, just the product key (and your API key, of course). This should simplify things for you.
masseyfHi again,
I tried the new implementation of getID and that works fine. Because we have so many products with so many PKs, we can't just drop all wyBuild files into a single folder. That would be simply unmanageable. The VersionID is the only *discoverable* value that can categorize a product key. So it would make sense to create folders on the web server based on the VersionID where the updates files could be saved to. Therefore I'm still finding myself wanting to discover the VersionID associated with the product key.The only method that returns the VersionID is the AdvancedSearch and it can't be used because of the amount of data it returns...
After thinking about it overnight, one possible avenue to solve this would be to provide the VersionID on the URL set in wyBuild since a wyBuild project is product specific, like so:
limit-update.aspx?update=%file%&pkey=%urlargs%&versionid=1234
I'm not too keen in providing a value that can be used to directly target a product in LimeLM, for security reason. Am I being paranoid? Would that pose a problem in your opinion? Would there be any other LimeLM "integrated" solution to this (like having the GetDetails api call return the VersionID)?
Thanks again!
limelm.pkey.getDetails now also includes the version_id. So now you can put the updates for separate versions in their own folders. And you don't need to include the version_id in the request / filename, just the product key.
masseyfHi Wyatt,
Just tried it and confirm it works.
I would like to point out that the change to pkey.getID is potentially very serious and may break logic. It does in our download site where we were relying on pkey.getID to validate that the PK provided by the customer actually matched the product selected. That was done automatically since the version id was used to get the id of the PK provided by the customer. Since the change, our site accepts any valid & existing key, related or not to the product selected. Basically, a customer can download any and all products using a product key.
This is not a dramatic issue because all the products available on the download site are secured with activation in the end and the new version of the site will use GetDetails to validate the version id against the product key. But worth keeping in mind for your other customers.
We considered that when removing the version_id requirement, and we were ok with it for a couple of reasons:
a. limelm.pkey.getID was always meant as a simple way to get the ID of the product key. The fact that it required a version_id was just sloppy initial design which never got addressed.
b. limelm.pkey.find has always been the best thing to use if you want to limit the search for a product key or email within a specific product version.