You could use a HTTPCaller to query an online time service such as this one (or just any webserver that you have set up)
You could use a HTTPCaller to query an online time service such as this one (or just any webserver that you have set up)
Its good approach but is there any other way from which I can extract the date from local system because this needs internet connection for validation
The Timestamper uses the system (BIOS) clock and that's, as far as I know, the only timekeeping that's being done on your system. You could consider an approach where you log what dates you've already had and on every run compare the system date to the log: if the system date is before a date you've already logged that's an indication that there might be something fishy going on (we'll ignore daylight savings time for now...), but if you're doing this for security reasons you'll need to understand that this can easily be circumvented too.
I agree with everything said by @redgeographics.
Maybe you should reconsider your licensing strategy, these date limitations are too easy to circumvent.
How about setting a limit on the number of features processed per dataset?
Sounds to me (too) that bullet proofing the transformation is necessary.
If it's for licensing purposes, don't forget we have a LicenseChecker transformer. You register with Safe, we give you a license generator, and you can generate/check licenses for a workspace/transformer. They can be given an expiry date, although I admit I don't know what happens if a user changes the system date. I would hope that FME notices!
It's an interesting problem. Re what @redgeographics suggested, it's hard to log info because it's external to the workspace. So I wondered if it would be of help to anyone if we had the ability to store a *small* amount of data inside a workspace? Just 10-20 characters or so. Enough to record "comments" or "header" info that you could read back. Technically you might do that now with the textfile reader/writer, but then it wouldn't work on encrypted (password protected) workspaces.
So, would anyone find that ability useful? If so, file an idea - or I can log it directly with our developers. I'd be interested if there are any uses for this other than what pratap requires.
It's an interesting problem. Re what @redgeographics suggested, it's hard to log info because it's external to the workspace. So I wondered if it would be of help to anyone if we had the ability to store a *small* amount of data inside a workspace? Just 10-20 characters or so. Enough to record "comments" or "header" info that you could read back. Technically you might do that now with the textfile reader/writer, but then it wouldn't work on encrypted (password protected) workspaces.
So, would anyone find that ability useful? If so, file an idea - or I can log it directly with our developers. I'd be interested if there are any uses for this other than what pratap requires.
I could see some value in that, if something could be stored in the workspace properties and then could be accessed at runtime (through a set of parameters). Off the top of my head the timestamp of the last run as well as succes/fail could be useful in certain scenarios. If you want to log more than just the last run it's probably best to make this optional to avoid things spiralling out of control on workspaces that are run often. I could also see this being disabled by default on FME Server (because the jobs log pretty much does that)
Hello Everyone,
Thank you for one and all participated in the thread. This is just a thought of adding licensing for workspaces as we are looking for other software's.
I thought adding the date on day-wise using Python in custom registry and verifying the same will do to some extent.
Still there are ways like formatting/changing the PC, but saving a small encrypted info (by opening the workspace itself without asking user to save or not) as suggested by @Mark2AtSafe will help to cross check as well.
I will post the Idea for a transformer to write registry info as I don't know Python :)
Hello Everyone,
Thank you for one and all participated in the thread. This is just a thought of adding licensing for workspaces as we are looking for other software's.
I thought adding the date on day-wise using Python in custom registry and verifying the same will do to some extent.
Still there are ways like formatting/changing the PC, but saving a small encrypted info (by opening the workspace itself without asking user to save or not) as suggested by @Mark2AtSafe will help to cross check as well.
I will post the Idea for a transformer to write registry info as I don't know Python :)
Just be aware that the part of the windows registry where you can write anything without admin privileges (HKEY_CURRENT_USER) is local to each user. This means that if another user logs in, the registry key you just wrote won't be available (not exist).
Just be aware that the part of the windows registry where you can write anything without admin privileges (HKEY_CURRENT_USER) is local to each user. This means that if another user logs in, the registry key you just wrote won't be available (not exist).
Thank you for the alert. This is just a thought as of now and still have to check the feasibility. Will check and get back
If it's for licensing purposes, don't forget we have a LicenseChecker transformer. You register with Safe, we give you a license generator, and you can generate/check licenses for a workspace/transformer. They can be given an expiry date, although I admit I don't know what happens if a user changes the system date. I would hope that FME notices!
Having tested this previously (for valid reasons of course) I can confirm FME does notice. Vigorously.
Having developed a licensing system from the ground up myself (in a previous lifetime), I can attest that it is surprisingly hard. Bascially, you have to balance security with user friendlyness, which can be really difficult when you have to account for every possible scenario. Honest users will only put up with so many barriers, and dishonest users won't be stopped unless there are several barriers in place.
If limiting usage is important, you will save yourself a lot of problems and headaches by going with something established.
I could see some value in that, if something could be stored in the workspace properties and then could be accessed at runtime (through a set of parameters). Off the top of my head the timestamp of the last run as well as succes/fail could be useful in certain scenarios. If you want to log more than just the last run it's probably best to make this optional to avoid things spiralling out of control on workspaces that are run often. I could also see this being disabled by default on FME Server (because the jobs log pretty much does that)
I suggested a couple of transformers that read/write the Workspace Properties History fields. That way you can write a date/username/comment and read it back next time. Whether they will go for the idea remains to be seen!
I suggested a couple of transformers that read/write the Workspace Properties History fields. That way you can write a date/username/comment and read it back next time. Whether they will go for the idea remains to be seen!
It could definitely be useful, but I cannot see how it would work as a licensing system:
- What would happen if the .fmw was read-only?
- What if the user makes a backup of the .fmw before the first time the workspace runs, then he restores the .fmw after each run?
I suggested a couple of transformers that read/write the Workspace Properties History fields. That way you can write a date/username/comment and read it back next time. Whether they will go for the idea remains to be seen!
@david_r Yes, these are other scenarios which needs to be considered. Hope adding registry entry and verifying will address to some extent.
It could definitely be useful, but I cannot see how it would work as a licensing system:
- What would happen if the .fmw was read-only?
- What if the user makes a backup of the .fmw before the first time the workspace runs, then he restores the .fmw after each run?
Yes, not sure I would use it for licensing (that's what the LicenceChecker is for) but it made me think you could use it for other things. eg I run a validation workspace. Some tests fail. I record those tests in the history so that next time I run the workspace I can skip the ones that pass. Something like that. I don't think it will happen anyway, but I like to file these ideas when I have them. Amazing how many crop up again years later. At the very worst it would be a way to record history automatically.
