I am Developing an onpremise solution for a client without any control and internet connection on the machine.
The solution is to be monetized based on number of allowed requests(REST API calls) for a bought license. So currently we store the request count in an encrypted file on the file system itself. But this solution is not perfect as the file can be copied somewhere and then replaced when the requests quota is over. Also if the file is deleted then there's manual intervention needed from support.
I'm looking for a solution to store the state/data in binary and update it runtime (consider usage count that updates in binary itself)
Looking for a better approach.
Also binary should start from the previous stored State
Is there a way to do it?
P.S. I know writing to binary won't solve the issue but I think it'll increase the difficulty by increasing number of permutation and combinations for places where the state can be stored and since it's not a common knowledge that you can change the executable that would be the last place to look for the state if someone's trying to mess with the system (security by obscurity)
Is there a way to do it?
No.
(At least no official, portable way. Of course you can modify a binary and change e.g. the data or BSS segment, but this is hard, OS-dependent and does not solve your problem as it has the same problem like an external file: You can just keep the original executable and start over with that one. Some things simply cannot be solved technically.)
If your rest API is within your control and is the part that you are monetizing surely this is the point at which you would be filtering the licensed perhaps some kind of certificate authentication or key to the API and then you can keep then count on the API side that you can control and then it wont matter if it is in a flat file or a DB etc, because you control it.
Here is a solution to what you are trying to do (not to writing to the executable which) that will defeat casual copying of files.
A possible approach is to regularly write the request count and the current system time to file. This file does not even have to be encrypted - you just need to generate a hash of the data (eg using SHA2) and sign it with a private key then append to the file.
Then when you (re)start the service read and verify the file using your public key and check that it has not been too long since the time that was written to the file. Note that some initial file will have to be written on installation and your service will need to be running continually - only allowing for brief restarts. You also would probably verify that the time is not in the future as this would indicate an attempt to circumvent the system.
Of course this approach has problems such as the client fiddling with the system time or even debugging your code to find the private key and probably others. Hopefully these are hard enough to act as a deterrent. Also if the service or system is shut down for an extended period of time then some sort of manual intervention would be required.
I am programming a 30-Day-trial application, I need to make sure if the user changes the system time it will not harm my application and the 30-day-trial will still be calculated, or at least I will be able to figure he did something wrong.
The best way I found is to check for a system file which its contents updated and every update contains the time with its data, so I can find out if the user changes the date or not, by comparing the dates with each other ...
I know it is not certain way, but it is kind of make it harder and shrink the area of who can crack it.
I found about Event log
windows7 log files
it can help..
Any solution proposed can be hacked. But it sounds like you only want to ward off the casual pirate, not the determined hacker.
Instead of trusting the system clock, how about just making a network request back to your own website or time server to get the current date and time?
Another idea is to just limit the number of times the application can be launched instead of limiting it to a specific amount of time.
I have a form that asks users to enter a start and end time for an event. For many years, we have allowed them to enter the times by selecting the hour (1-12), minute (1-60), and AM/PM from three drop down boxes. This has worked fine without complaints from customers. However, today I was hit with a request to change the input to one text box for the user to enter time in military time (aka 0000 - 2359). In my gut I believe this is a bad idea but am having trouble coming up with any hard facts.
What are the best reasons I can give that this would be a bad idea?
If there is a better solution for entering time, what would it be?
Also, FYI the users filling out the form run the gamut from very little skill with computers to advanced users. They are in no way military related.
Update: All my users are local and no other forms (web or print) use military time as the standard.
Three dropdowns are a nightmare usability-wise. You can cut these down to two by eliminating AM/PM and moving to 24-hour format, but still: a dropdown with 60 items is overkill.
I'd much prefer to enter time "manually", provided that these input boxes will be intelligent enough (say, they should be able to convert 18 to 1800, 0 to 0000, allow : as a separator, etc.). Plus do not allow users to enter incorrect data in the first place.
To answer your question: I see no reason to disallow your users to do what they want. After all, they are users.
Well, from a user interface standpoint, this could be a mistake simply according to some of Jakob Nielsen's user interface heuristics:
"Match between system and real world." If your users are not used to entering dates in military time, asking them to do so for your app can be distracting at best, and frustrating at worst.
"Error prevention" You are not eliminating error-prone conditions, but possibly introducing them.
There is also the question of why this change is being made. Are customers complaining? Is data coming in incorrectly? As mentioned by others, are your users used to military time? Any interface change should happen for a reason, IMO, because you're going to change the user experience and there will be ramifications for that; it's just a matter of how large those ramifications will be. My assumption is that data entry errors are supposedly going to be avoided -- but are they? Asking a user to enter a time as "XX:XX" and parsing out the semicolon (or, as Aaron Digulla stated, ANY non-number characters) and then converting it as needed seems less likely to result in errors than asking a user to enter a time in a format they are not used to using daily.
My concern would be that a user wants to enter 3:30 PM, and, while not paying much attention, simply enters 330. This is now 3:30 AM, and the user will never know the difference, because the app takes the information and happily assumes that this is what is meant. However, allowing the user to enter the time in "XX:XX" format and having an "AM/PM" selection makes much more sense.
As far as hard facts, well, I don't have them either. But if your boss/client won't be swayed by Nielsen's heuristics, I'm not sure what can change their mind.
Oh my.
My advice is to quit and find a different project.
We did a scheduling app for a "military customer" - and even they could not agree on what constituted "military time". Half of them wanted something called "Zulu Time" - the other half wanted "GMT plus offset" - then some wanted local time in 24h format. Contrary to what our contract specified, a Colonel insisted we use "Zulu" - we made the change for political reasons (in violation of our contract) - and then HE missed showing up for a scheduled event, because he thought it was in local time. Then contract management came down on us like a ton of bricks.
(never mind that the published schedule also used an obsolete "offset" that was a cold-war holdover meant to "fool the Russians").
In that this is just me sharing a war-story. . .
The real answer is to Elicit Requirements from your customer. Get those requirements SPECIFICALLY written into your contract. Make sure that the stakeholder who is actually writing your check, agrees. Develop to that specification exactly. When someone complains tell them to pay for a contract mod. You'll probably be changing this back and forth among many different settings for the next 10 years. You'll have steady work, and you'll understand why military contracts frequently go way over budget and are never on schedule.
"They are in no way military related."
That's a good enough reason for me. It's an uncommon format that, while not exactly "user-hostile," is nonetheless not the way most of us are used to seeing dates, and requiring your users to do the conversion in their head will lead to arithmetic errors eventually.
That said, drop-down boxes aren't great either. Best to go with 2 input boxes and an AM/PM dropdown, in my opinion.
It may not be a bad idea. Imagine the case where users must enter that bit of information lots of times, for example because they are in call support. Or they may find the dropdown boxes not usable enough, even after having tried them. They may prefer that other format.
It is usually a good idea to talk to the stakeholder and ask him: "Why do you want it this way?" you can then contrast their ideas with yours, but if yours are only that you have the "gut" feeling that this is not right, guess who will win the argument. The gut feeling is not a valid business argument - especially when the business is not yours.
So in short, do what your customer wants - just make sure that they understand their options well, and point out to them any inconvenience that they may have foreseen - once you find one, that is.
Honnestly, I think using AM/PM format is a bad practice, but that may be because I'm used to the 24 hours scale.
One reason against is that if all your users are used to the 12H scale, then most of them might still enter 1:00 instead of 13:00 for 1:00. Since the PM is not here, it will result in mistakes.
However, one good reason to do the switch is simply because it's the international standard.
Depending of what you want to put the emphasis (speed or functionality) you can use a time picker that would rely on regional setting to diplay the time in the user format or use a clock-like control. If speed is important, you might prefer a simple mask-textbox.
Hmmm, describing the 24 hour clock as "military time" and then noting that the users are not military makes me a more than a little twitchy.
It will depend on your users but I think that it is more than reasonable to expect people in contemporary society to understand the 24 hour time format and to be able to enter times using that format (given that I would - possibly naively - expect that format to be in use for bus, train, plane and other timemtables almost universally for the simple reason that its unambiguous). Perhaps this is not true worldwide - but it is certainly true across Europe.
That said, changes need to be made for a reason - "if it ain't broke..." is a very sound maxim for a working site and whilst I wouldn't ever willingly use am/pm for time entry I don't have a problem with use of dropdowns for time entry - especially as one can type "into" them. In this case I think that going from drop downs to text boxes is most likely an opportunity to introduce errors (although again it rather depends on the users).
I can see why you think this is a bad idea, silly users input wrong format etc.
However have you considered a jQuery Masked input box?
In my own frames, I accept times and dates in a wide variety of formats. When the field loses focus, I'll try to parse the input and format it into the "correct" or "official" format. This gives the user a nice way to enter the data and a visual cue when something is wrong.
For example, in a date field, I'll accept "1" as "01.12.2009" (current month+year). In a time box, I'll accept "1030", "10 30", "10.30" (i.e. I just filter out anything which isn't a number). "010409 1125" becomes 1. April 2009, 11:25am.
Few outside the united states knows the words "military time". They also prefer 24-hour format.
If you want globalization, you can do one of the two:
use accepted and de-facto standards, such as ISO8601 date format, 24h time and speak English
dive into the nightmare of the vast regional-based localization complexity (some unfortunate programmers have to do it anyway. Then they support AM/PM, unicode and never-showing-yellow-color for certain cultures)
I cannot believe how much consideration this idea has gotten.
Forcing your user to do things your way, because it's "more efficient" is a terrible idea.
Your forms should be both streamlined (power users can enter data quickly from the keypad) and comprehendible (first time users can navigate successfully). The conversion to 24 hour time will throw people immediately. I lived in Quebec for almost six years and still had troubles switching back and forth from 24hour time. DON'T DO THIS.
Just in addition to all the rest of comments you should thing about one more thing.
Programmers and designers usually think the client pays us just for creating what he tells us to... That's only half true. They pay us, even if they don't realize it, for telling them what they need, what's best for them.
Of course, the final decision is always theirs, as the pay, but if you feel it is wrong and you think you know the business model better than them, then do not blindly accept whatever they told you to do.
You might want to consider using the jQuery timepicker (or Telerik DateTimePicker in Time-only mode for WinForms) and also build in support, on the backend, for multiple formats in the event that javascript is disabled.
date/time input through select boxes is a horrible UI design.
but, if some of your users come from the few countries that stick to AM/PM for time format, then forcing the "military" format on them without assistance from the program is also bad.
use something like the jQuery masked input plugin.
if i was doing this, i would use a masked text input and a "PM" checkbox: if the value is more than 1259, the checkbox is disabled. otherwise, it's clear by default.
Why not use a TimePicker control of some sort?
You shouldn't force non-military users to user a strange to them time format.
In any case, assuming that all input is by logged-in users, you can provide multiple mechanisms (and certainly multiple ways if displaying time) and make the choice a user preference. But I'd strongly recommend that whatever you do, for any given user times should be entered and displayed in a consistent manner.
Is thee some way of implementing a custom time zone in windows?
We have some PCs in Creston, British Columbia, Canada (Time zone exception) which stays the same time all year. So essentially, Creston does not observe a time zone. Can I implement this behavior in windowsÉ
I wrote a lengthy blog post about a similar problem we had: http://subjectivecoder.blogspot.com.au/2013/04/creating-custom-windows-timezones.html
The short version is that there is a spot in the registry which allows you to modify or create new time zones - but the registry format is fairly nasty.
Microsoft has a GUI tool called TZEdit which you can find here: http://support.microsoft.com/kb/914387 (scroll down to Method 2 and download TZEdit.exe).
If you want to see what's going on behind the scenes, I've published the source to the command line tool I built here: https://github.com/Rophuine/TimeZoneInfoGenerator (it's untested and quick-and-dirty but may help you understand what's going on, if you're interested).
Apart from daylight savings time, this is normal MST (UTC-0700), right?
Windows used to have a checkbox called something like "Automatically adjust the clock for daylight savings time". Maybe you can hunt that down. Even if there is no checkbox, chances are that the registry setting still exists.
The data is in: HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Time zones.
You can probably add your own zone.
Each zone has its own key. And they contain a lot of data. Some zones have a subkey Dynamic DST.
This is not exactly an answer, but you might consider trying to get Creston recognized as an official time zone. As for how exactly to do that... contact Microsoft, I guess, and ask where they get their time zone info from. Probably the closest thing to an official time zone database in computer programming is zoneinfo but I'm not sure if Microsoft uses it.
WARNING: You should be very careful about creating your own time zone, even if you think your systems are isolated.
This could cause problems with exchanging information with other systems, both from conversion errors as well as exception handling.
If the time zone you want is legally recognized, you should consider bothering your vendor to properly add you to the time zone repository they use.