There are legitimate times when the clock goes backwards. DST for one,
user error for another, repairing a drifting clock a third.
Also, the client cannot be trusted with providing any security-sensitive
data since he can easily screw any client-side "security" over thrice by
attaching a debugger.
So either the timestamps are not security-sensitive after all, then
there is no need worrying about them. Or they are sensitive and need to
be calculated, written, and protected by an entity not under the
influence of the user.
In the case that the target environment is so tightly controlled, that
the user cannot extract the database connection string and/or password
by disassembling the client (soft- AND hardware) you might get away with
properly synchronizing client clocks. Since you've asked the question
you've asked, I do not think you are in such a situation.
D.
PS: see
http://security.blogoverflow.com/2011/09/storing-secrets-in-software/
for a tangential but related topic.
On 02.11.2011 14:27, TheCPUWizard wrote:
Marios,
Yes there are other considerations for a robust system. But just think
about the implication of a user changing the time on the computer.
Either the original time was wrong or the new time is wrong. But either
can be compensated for by using something (e.g. Stopwatch) which
increments time independently of the system clock once the time has been
dealt with once.
David
*From:*[email protected] [mailto:[email protected]] *On
Behalf Of *Marios Skounakis
*Sent:* Wednesday, November 02, 2011 1:18 AM
*To:* [email protected]
*Subject:* Re: [nhusers] Timestamping records in desktop application
This sounds very interesting. It certainly is efficient.
One problem is how can you guard against the user changing the machine's
clock time - I think you can subscribe to some TimeChangedEvent and
query the database again...
On Wed, Nov 2, 2011 at 01:10, TheCPUWizard <[email protected]
<mailto:[email protected]>> wrote:
Alternatively, just query the database once, set an offset, and be golden…
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *[email protected] <mailto:[email protected]>
*Sent:* Tuesday, November 01, 2011 2:20 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [nhusers] Timestamping records in desktop application
why not just put them in a trigger in the db?
On , Marios Skounakis <[email protected] <mailto:[email protected]>> wrote:
> Hi all,
>
> Consider a desktop application in which you want to timestamp records
(store the current date in fields "DateCreated" and "DateUpdated").
Since it's running on the clients you can't reliably use DateTime.Now as
each client may have a different time, instead you somehow need to get
the database time.
>
>
> Things I have considered:
> 1. Getting the time from the database every time you need it (e.g.
before inserting or updating each record). This can be slow.
> 2. Use an interceptor to get the time from the database at session
flush and update the respective fields for all entities.
>
> 3. Use generated properties. This sounds bad too as it requires an
extra select for each insert/update.
>
> (2) seems to be the best solution. Do people agree? Is there a better
approach for this?
>
> On a related note, if you have a datetime or timestamp version
property, how does NH set its value? In principle, if you have a record
that was just inserted and never updated, DateCreated, DateUpdated and
the version property should all have the same value.
>
>
> Thanks in advance,
> Marios
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google
Groups "nhusers" group.
>
> To post to this group, send email to [email protected]
<mailto:[email protected]>.
>
> To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
>
>
> For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
>
>
>
>
--
You received this message because you are subscribed to the Google
Groups "nhusers" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
--
You received this message because you are subscribed to the Google
Groups "nhusers" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:nhusers%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
--
You received this message because you are subscribed to the Google
Groups "nhusers" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
--
You received this message because you are subscribed to the Google
Groups "nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
