Skip to main content
Question

Date Constraint

pratap
Contributor
Forum|alt.badge.img+11

Hi Everyone,

I want my work benches should work between the defined dates (eg: From 1-Apr-2016 to 31-Mar-2017). If the work bench is executed after those dates (eg: 1-Apr-2017) then work bench should fail.

For this, I have defined From date with attribute creator and current date with the help of TimeStamper and downloaded DateDifferenceCalculator from store and checked the difference and it is working fine with a tester. But the problem arises when the system date is altered manually, TimeStamper is considering modified date instead of actual current date.

Does any one suggest the best alternative approach to attain even the system date has been changed manually.

Thank you in advance

17 replies

redgeographics
Celebrity
Forum|alt.badge.img+49

You could use a HTTPCaller to query an online time service such as this one (or just any webserver that you have set up)

pratap
Contributor
Forum|alt.badge.img+11
  • pratapContributor
  • Author
  • Contributor
  • September 14, 2016
redgeographics wrote:

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

redgeographics
Celebrity
Forum|alt.badge.img+49

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.

david_r
Celebrity
  • david_rCelebrity
  • September 14, 2016

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?

itay
Supporter
Forum|alt.badge.img+17
  • itaySupporter
  • Supporter
  • September 14, 2016

Sounds to me (too) that bullet proofing the transformation is necessary.

mark2atsafe
Safer
Forum|alt.badge.img+44
  • mark2atsafeSafer
  • Safer
  • September 14, 2016

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!

mark2atsafe
Safer
Forum|alt.badge.img+44
  • mark2atsafeSafer
  • Safer
  • September 14, 2016
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.

 

redgeographics
Celebrity
Forum|alt.badge.img+49
mark2atsafe wrote:
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)

 

 

pratap
Contributor
Forum|alt.badge.img+11
  • pratapContributor
  • Author
  • Contributor
  • September 15, 2016

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 :)

david_r
Celebrity
  • david_rCelebrity
  • September 15, 2016
pratap wrote:

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).

 

pratap
Contributor
Forum|alt.badge.img+11
  • pratapContributor
  • Author
  • Contributor
  • September 15, 2016
david_r wrote:
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

 

 

T
Forum|alt.badge.img
  • turner537
  • September 15, 2016
mark2atsafe wrote:

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.
david_r
Celebrity
  • david_rCelebrity
  • September 15, 2016

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.

mark2atsafe
Safer
Forum|alt.badge.img+44
  • mark2atsafeSafer
  • Safer
  • September 15, 2016
redgeographics wrote:
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!

 

 

david_r
Celebrity
  • david_rCelebrity
  • September 15, 2016
mark2atsafe wrote:
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?
pratap
Contributor
Forum|alt.badge.img+11
  • pratapContributor
  • Author
  • Contributor
  • September 16, 2016
mark2atsafe wrote:
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.
mark2atsafe
Safer
Forum|alt.badge.img+44
  • mark2atsafeSafer
  • Safer
  • September 16, 2016
david_r wrote:
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.

 

Reply


Helpful Members This Week

Community Stats

31,336
Posts
118,868
Replies
38,958
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.