This question may be easy and the answer obvious, but I can't seem to be able to find a solution right now.
I built an application which has a big flaw in it. In a property of my User class, I check to see if the user subscription is expired. To do this, I compare the ending date of the subscription with DateTime.Now:
return (DateTime.Compare(DateTime.Now, subEndDate) > 0);
It doesn't take a genius user to realize that all it is needed is to change the Windows date to an earlier one, and then the application won't expire at all. So I think that comparing to DateTime.Now should not be done, is there a better method that I could use in order to validate a subscription date?
Thanks.
Regards,
Call a webservice or check a database to determine if the subscription is still active
Does this actually matter? If your product is purely web based the only time you have to worry about is your server time. If the server time is able to be altered without your consent you probably have larger problems to worry about.
If your product is desktop based, then how much protection do you want build in? If you just want to protect against your casual user the solution you have is probably enough. If someone is determined to pirate your software then they will probably be successful. If you want to make it harder for these users one solution would be to keep a log of all the times the application has been run. This way you can get an idea of they are playing with the clock.
Maybe you could extract the subscription expiration logic out of your client program and put it into an external service, then your client app could connect to a different server and retrieve expiration details based on a user parameter passed in?
There are several NTP servers out there which you can use for free... they return the exact time and your casual user won't have a hand in manipulating those... to access them you have several options - though none built-in:
http://dotnet-snippets.com/dns/simple-network-time-ntp-protocol-client-SID571.aspx
http://www.codeproject.com/KB/IP/ntpclient.aspx
http://www.codeproject.com/KB/datetime/SNTPClient.aspx
http://www.rebex.net/time.net/ (commercial)
Related
I've ran into an issue which i'm struggling to decide the best way to solve. Perhaps my software articheture needs to change?
I have a cron job which hits my website method every 10 seconds and then on my website the method then makes an API call each time to an API however the API is rate limited x amount in a minute and y amount a day
Currently i'm exceeding the API limits and need to control this in the website method somehow. I've thought storing in a file perhaps but seems hacky similary to a database as I don't currently use one for this project.
I've tried this package: https://github.com/David-Desmaisons/RateLimiter but alas it doesn't work in my scenario and I think it would work if I did one request with a loop as provided in his examples. I noticed he had a persistent timer(PersistentCountByIntervalAwaitableConstraint) but he has no documentation or examples for it(I emailed him incase). I've done a lot of googling around and can't find any examples of this only server rate limiting which is the other way around server limiting client and not client limiting requests to server
How can I solve my issue without changing the cronjobs? What does everyone think the best solution to this is?
Assuming that you don't want to change the clients generating the load, there is no choice but to implement rate limiting on the server.
Since an ASP.NET application can be restarted at any time, the state used for that rate-limiting must be persisted somewhere. You can choose any data store you like for that.
In this case you have two limits: One per minute and one per day. If you simply apply two separate rate limiters you will end up with the daily limit being exceeded fairly quickly. After that, there will be no further access for the rest of the day. Likely, this is undesirable.
It seems better to only apply the daily limit because it is more restrictive. A simple solution would be to calculate how far apart requests must be to meet the daily limit. Then, you store the date of the last request. Any new incoming request is immediately failed if not enough time has passed.
Let me know if this helps you.
I want to build an application to email field workers in our company when their passwords have expired. I'll be using some type of C# application while communicating with Active Directory.
I also want to ensure that users do not get emailed every single day/night, as this sounds a bit obnoxious. The idea I have is to create a web application with no UI, and have a global list of emailed users that never gets reset, just gets updated (user gets added when they are emailed, and get removed when their password is no longer expired). So I'll fill that list with a user object containing their samaccountname and the day they were emailed. If they are in the list, I don't want to email them again.
However, upon doing some reading, I found that multiple sources said that having a non-interactive web application to be executed on a schedule isn't a good way to do it. Instead, it seemed people were fond of Windows Services, which is something I don't know a lot about.
What would best practice to implement something like this? My ideas might also be completely off. Thanks for any insight.
Edit: New idea - Perhaps using an SQL table would be a better idea than a global list.
Yes, you're absolutely right about the storage, sql or nosql should do the job.
My advice is to store the the information you have describied in some database, this way you will have secure and long-living storage about the data (scenarios like power-cut, network drop or even simple restart of the server won't lead to loosing the information about the send emails).
Using the task scheduler with simple console application will be just fine. It sound more close to your needs (executing checks and notification at periods).
If I use DateTime.Now as part of software licensing authentication to enforce the number of days software can be used, can this be circumvented by simply changing the system clock?
If so is there a better way to get real UTC time?
If I use DateTime.Now as part of software licensing authentication to
enforce the number of days software can be used, can this be
circumvented by simply changing the system clock?
DateTime.Now uses the system clock, so yes it could be circumvented.
If so is there a better way to get accurate system time?
Yes, you could query a time server over the www. But you know, even this could be circumvented because the user can modify his hosts file and replace the address you are using with his own proxy and return whatever time he likes. So it will all depend on how far do you want to get into protecting your software. If you really care about the intellectual property of your software you are better of purchasing a commercial licensing software.
Everytime i have used this method for testing it has affected this, so the answer is yes it does affect it
Yes of course, the DateTime.Now obtains its value from the system clock.
A better way is to use a NTP server on Internet.
In this article on codeproject you could find code that allows a client to connect to a NTP server
I need to create a Windows service that checks when a user logs in windows (in a computer with several users) and when the users logs out (or lock the computer) and with this information calculate the time the user has been logged in (I don't care about idle time) or better if I can get this last piece directly. (I don't mind if the user pull the cord, the service will be polling the current user and logging this information so I will know if the computer was turned off that way the next time it wakes up. It does not has to be exact).
I need to know this in order to kick the user out when they exceed certain limit of time.
I will be using either C# or Delphi, I'd appreciate to point me out which API's to look for to get this information.
There's already software around that checks this like that targeted to check the kids computer usage, I need something like that, but I will customize for another purpose than watch kids.
Actually, I may just need to know when the user logged in, and from that I will calculate the rest on my own.
Try the Win32_LogonSession WMI class, check the StartTime, LogonId and LogonType properties. Also you can take a look to the Win32_Session class.
The origin of the information come from SECURITY_LOGON_SESSION_DATA. You can use LsaGetLogonSessionData or LsaEnumerateLogonSessions. To get session Id of the thread (or user logon token) you can use GetTokenInformation with TokenSessionId as parameter.
In the old answer you will find the source code of the small demo.
If you need monitor user login and logoff I would recommend you to implement ISensLogon2 callback interface (see of the System Event Notification Service (SENS)) in your windows service. If you plan use it in C# I would recommend you the article.
You'll need to probably interrogate the windows event log to get this information. Eric Fitzgerald talks about some of this here. Note also that he links to here, on how relying on the "LogOff" event is, well, unreliable. This mentions my comment above, about people pulling out the power-chord.
The articles also mention the idiosyncrasies involved, such as the work-station being locked, etc...
I'm developing an application and I need to make a demo version of it that will expire in lets say 30 days.
My idea for now is to store the current time when the application is first started in a simple txt file stored in the projects resource (so it doesen't have to be written on the hard disk or the registry), and every time the program is started check if 30 days have passed.
But, what if the user resets the time to an earlyer state?
Then my app would still start becouse now the "current date" can be 1 day after the "first start"..
Is there any way I can get some info along with the first date (or, insted of) that would assure that specific time that the application is first started?
Thank you for your time.
One of the option is to check the date time from some external server and not from local system. But this is also possible to crack as the user can put a proxy in between which will act as the external server to your app and this proxy can send any time the user want. In case you want the solution for novice users, external server approach is fine, but any smart user can still crack the application. Remember, any code that runs on a client machine can be cracked, you just need to flip the correct bit in the application code :)
I have a simple check in the code of one of my programs when in beta. It pretty much does what you say. In the initial code is a hard coded date. The logic then just tests to see if the current date is earlier than the hard coded date. Pretty primitive and it relies on the users system date. However once it is past the program will not run unless the system date is changed. As I mention I use this for betas not for my production programs that have an evaluation period. For that I use Infralution License Tracker. This is payware but it does allow the setting of evaluation periods and also the actual licensing of the code.
Interesting question - how about encoding the initial datetime somehow - base64 or even encryption of somekind), then also storing the datetime each time your application is run.
That way you can detect inconsistencies by checking each datetime and if there's funny business going on (eg. todays date is older than the last date) you can shut the user out.