I am trying to license my product(java app) with a simple technique by comparing two dates.I want to know how should I increment the date when I give the app to my client.I need to increment the date everyday,so that when it expires it doesnt work.
I dont want to use the system date,cause there are chances the client might change that.So could anyone provide me any suggestions.
Since the java app is going to be running on your client, you have basically two options (simplistically speaking).
Option1. Use a (possibly) encrypted file on your client's filesystem to store the date you want to store and compare against your expire date.
Option2. Upon registering, register to a server. Now the server knows when you registered, so it should be able to determine when you expire. Each time the application starts, make a call to the server asking if it has expired. This way, you have transferred part of the expiry logic to the server.
Keep in mind that both approaches in their simplistic form can be easily circumvented but that is most of the time the case when you have an app running on clients' computers.
One way i can think of is
Use webservice to get current date in your client
earthtools.org provides a free web service to get the time zone from a city here:
http://www.earthtools.org/webservices.htm#timezone
You just pass in the long/lat values like this: (This is for New York)
http://www.earthtools.org/timezone-1.1/40.71417/-74.00639
Use java Rest client to get date in your code
http://www.mkyong.com/webservices/jax-rs/restfull-java-client-with-java-net-url/
Related
I have an application which is used by all over world. But the application server is present in India.
One of my application features is
**create template using date
So, for that I have to store the client systems date & time.
But I need to store date time based on Client side or server side in single column in database?
What is the best approach to do this?
I think you have a few options here, depending on how you wish to delegate responsibility and how the templates will be used.
The simplest solution is simply that the client submits the date & time and you store it as is with no time zone information. This however assumes that the template would only be used in the same time zone, or that it is acceptable to have the same date & time visible everywhere according to where it was created (probably not the best approach for a worldwide system)!
Another option is that you store the value as UTC. Then you can either:
Make the client responsible for converting to their local time
zone
Store the offset / time zone separately and include it in the result
This is probably the best approach
Or another option is to store the date & time together with the time zone it was created within. Then you might have to convert between different time zones either on the server or client side if you need a different one.
Is it possible in Android to get a time / date, which can not be manipulated by the user?
I mean in Android you can edit the system time and if you remove the battery the time is reseted too. Of course you can get the current time from a server on the internet but (improbable but is would work) then the user is able to intercept the request and send an own time back.
I do not know much about GPS. Is there a time stamp and is it possible that the user can replace it? I really want a time which can definitely not be changed by the user. Is that possible?
You can never trust the client. If this is really as absolutely crucial as you're saying, see if it's possible to offload whatever it is you're doing to a server that's under your control.
Actually
Date date = new Date();
will give us date of that server where application is running.
if particular server has set date and time wrong in that case how we can get real date and time?
I would not worry to much about the server's correct date. I mean a server is usually administrated by you, so just set the time correctly or use NTP to automatically set the correct time.
It is more the client's date/time you should worry about since this is set by your users and can be wrong all the time. If you need to trust the time on client and need it to be reliable and comparable for several users, then retrieve the time from your server and account for latency, if need be.
I have a little GAE application, a backend for my Android app.
I have a servlet in the app that pulls data from the datastore and send it to the user.
I don't want anyone to be able to use this servlet, so I store a private key in the app, and for every request I'm sending a token - a hash string of the private key and the current milliseconds, and the milliseconds I've used in the hash.
The server is taking the milliseconds and the private key, and comparing it with the token. If it went well, the server is storing the milliseconds in a HashSet so it will know not to use it again. (Someone can sniff the device data - and send the same milliseconds and token over and over again).
At first, I held a static field in the Servlet class, which was later discovered as mistake, because this field is not persisted, and all the data is getting lost when the instance get destroyed.
I've read about Memcache, but it's not an optimal solution because from what I understand, the data in the Memcache can get erased if the app is low on memory, or even if there are server failures.
I don't want to use datastore because it will really make the requests much slower.
I guess I'm not the first who is facing the problem.
How can I solve it?
I used a reverse approach in one of my apps:
Whenever a new client connects, I generate a set of three random "challenges" on the server (like your milliseconds), which I store in memcache with an expiration time of a minute or so. Then I send these challenges to the client. For each request that the client makes, it needs to use one of these 3 challenges (hashed with aprivate key). The server then deletes the used challenge, creates a new one and sends it to the client. That way, each challenge is single-use and I won't have to worry about replay-attacks.
A couple of notes on this approach:
The reason I generate 3 challenges is to allow for multiple requests in flight in parallel.
The longer you make the challenge, the less likely it will be that it will be randomly reused (allowing for a playback attack then).
If memcache forgets the challenges I stored, the app's request will fail. In the failure, response I include a "forget all other challenges and use these 3 new ones: ..." command.
You can tie the challenges to the client's IP address or some other sort of session info to make it even less likely that someone can "hack" you.
In general, it's probably always best to have the server generate the challenge or salt for an authentication than giving that flexibility to the client.
Another approach you could use if you would like to stick with using a timestamp is to use the first request interchange to determine the time offset between your server instance and your client device. Then, only accept requests with a "current" timestamp. For this, you would need to determine the uncertainty with which you can get the time offset and use that as a cutoff for a timestamp not to be current. To prevent replay-attacks within that cutoff period, you might need to save and disallow the last couple of timestamps used. This, you can probably do inside your instance since AppEngine, AFAIK, routes requests from the same client preferentially to the same instance. Then, if it takes longer to shut down an instance and restart one (i.e. to clear your disallow cache) than your "current"-cutoff is, you shouldn't have too many issues with replay-attacks.
I'm working on a system that does a bunch of stuff, as well as monitors the current date on a system, checks it against a stored date in a database, and if both dates are exactly the same, sends an email automatically to a bunch of users.
Now, I've been able to do everything else (the email sending, reading data from the database, you name it), except the monitoring part. What technique do I employ such that once the program is running, and the user is using the program, some part of that program is also carrying out checks on system date and the date stored in the database?
Any suggestions will be appreciated.
Thanks.
If you want your check to run periodically (for example, once per day), use java.util.Timer and java.util.TimerTask, or some kind of scheduler library like Quartz.
Each check would involve making a query against the database to check if the emails need to be sent.
See this article for more information, and examples: http://oreilly.com/java/archive/quartz.html
Instead of using scheduler (Quartz or cron), or start a thread at target time, I'd recommend you to use ScheduledExecutorService.scheduleAtFixedRate to check periodically.
Advantages against other approaches: 1. it will reflect latest DB change at the moment. 2. it is easier to implemnt. 3. the logic can be reused or unit tested
Get the target-date from the database, calculate the time from now to the target-time and start a thread that sleeps for the calculated time and triggers your main-program again, when the sleep-time (target-time) is reached.
This will work when no changes to the target-time (in the database) are expected.
Otherwise you have to check your database periodically and reset your sleeping-thread if needed.
you can use mailScheduler for this re fer this
http://www.oop-reserch.com/scheduler.html
Unless the timing of the email sending is critical, you could just add a cron job to start the check every hour or so, rather than continously run.
In terms of the check itself, you could store the values in the DB using the to string method in DateFormat, and when you perform the check revert the string to a Date using the String constructor and compare.