Timestamps Change During Network Transport

[TPRJones]

This seems like a stupid question, but is it possible for a time stamp included as text on a web page to be altered during network transport of the data?

See, we have these data collection processes we run and when it hasn't yet collected it says something like "data collection will begin on mm/dd/yyyy at hh:mm". In the past these dates and times have always been roughly an hour or less in the future, never have they been in the past. Recently past dates and times have been displayed, so something is wrong with that system. It's also not collecting data which is the bigger problem, but that's not the weird part.

Here's the weird part. If I access the collection from my computer at work it says "1/5/17". If I access the collection from my computer at home it says "1/17/17" on the same collection. Fine, something different about the computers maybe?

But no. My boss uses a laptop. He connects it to our wired internal network and he gets "1/5/17". He clears all caches and connects it to our wireless internal network and he gets "1/11/17". He clears again and connects simultaneously to our wired and wireless internal networks and he gets "1/8/17". He clears again and connects from his home network and he gets "1/17/17". He does it all again in a variety of orders with multiple different browsers and gets the same weird results in each of the above scenarios for each connection method.

The vendor assures us that nothing in their system can possibly relate that date stamp to the method of connecting to the server from their end. But what the hell else could it be? Is there any conceivable portion of TCP/IP internet connectivity that could lead to time stamps to be altered during network transport? Or does this just have to be some sort of weird crap on their end?

[TheCatt]

Sounds like bad caching or load balancing on their side? I am not aware of anything in transport that would alter content of a site.

[TheCatt]

Or perhaps bad caching by your network's firewall, if it does that.

[TPRJones]

I forgot about network caching on our end as a possibility. Although 12 days old? That seems excessive. And whenever the collections do eventually work (in those few cases where they do) we haven't had a case where it was showing as collected from one location while showing a cached old not-collected output from the other.

Plus there's that wired+wireless result that is really confusing. If wired gives "1/5" and wireless gives "1/11" and there's a caching issue then connecting both should give one or the other result depending on which cache is accessed. Not an average of the two ("1/8").

Thank you. It gives me something else to consider. But it's still weird as hell.

[TheCatt]

I can try it from here if you want. I have a few networks I can try.

[TPRJones]

I'm not really authorized to hand out the level of access to that system needed to see the collection status report, sadly. I may try a few proxies from home tonight, but I suspect everything external to our company network is going to come back with the "correct" timestamp. With the server we are accessing far outside that network.

[Malcolm]

is it possible for a time stamp included as text on a web page to be altered during network transport of the data

It's always possible to jack and alter your data if your security practices are imperfect. It's a matter of who have you pissed off and what resources they have.

So, your work machines do this...

But no. My boss uses a laptop. He connects it to our wired internal network and he gets "1/5/17". He clears all caches and connects it to our wireless internal network and he gets "1/11/17". He clears again and connects simultaneously to our wired and wireless internal networks and he gets "1/8/17". He clears again and connects from his home network and he gets "1/17/17". He does it all again in a variety of orders with multiple different browsers and gets the same weird results in each of the above scenarios for each connection method.

Wired, internal = 5-Jan-2017
Wireless, internal = 11-Jan-2017
Wired + wireless, internal = 1-Jan-2018
Boss's home, external = 17-Jan-2017 (today, correct)

I assume the system clocks on your work computers are fine, along with time zone settings and all that bullshit?

Is this it? Then you have data collection things which somehow express timestamps on a web page an hour before they start? Those timestamps are always expressed as simple HTML text? Do you have access to the mechanism which injects the HTML? If so, what is it?

[GORDON]

Screwed up record fetch, showing the timestamp of.the previous random record?

[TPRJones]

Those timestamps are always expressed as simple HTML text? Do you have access to the mechanism which injects the HTML? If so, what is it?

Okay, having dug into the the backside of this piece of crap, it's mostly written in Javascript. Yay.

It looks like the text for the time stamp is being displayed as simple text. I've isolated the code that pulla and update this information, and it looks like it just uses an ajax call to get content and then display the text. Or can an ajax call include injecting more code that I can't see in which might be some code that runs that may try to create the timestamp on the fly and fail for some reason?

Code: Select all

updateNextSteps: function()
  {
    // make an AJAX call to get the next steps text and update the page with the results
    EvidenceSetDwrFacade.getNextSteps( this.evidenceSetId, function( response )
      {
        if ( response )
        {
          $( 'nextStepsContent' ).innerHTML = response;
        }
      }.bindAsEventListener( this ) );
  },

If it's plain text or served up by the server itself it should be the same everywhere, unless the server is providing different information. But if that ajax call can pull in more code then maybe that's where it's hiding from me.

But don't bother yourselves more on this. It's too much of a mess with not enough information. And it's probably either a caching thing or something weird they are doing on their end.

[TheCatt]

Well, I started Javascript like yesterday for the first time in 15 years... so I'm an expert.... uh, looks fine to me?

Can you make the ajax call yourself?

[TPRJones]

Nah, it's calling to the vendor's server and I don't have that sort of access I'm afraid.

[TheCatt]

Nah, it's calling to the vendor's server and I don't have that sort of access I'm afraid.

fiddler to attach to the process?

[Malcolm]

Nah, it's calling to the vendor's server and I don't have that sort of access I'm afraid.

fiddler to attach to the process?

Ftw. Used that a lot.

[Malcolm]

Those timestamps are always expressed as simple HTML text? Do you have access to the mechanism which injects the HTML? If so, what is it?

Okay, having dug into the the backside of this piece of crap, it's mostly written in Javascript. Yay.

It looks like the text for the time stamp is being displayed as simple text. I've isolated the code that pulla and update this information, and it looks like it just uses an ajax call to get content and then display the text. Or can an ajax call include injecting more code that I can't see in which might be some code that runs that may try to create the timestamp on the fly and fail for some reason?

Code: Select all

updateNextSteps: function()
  {
    // make an AJAX call to get the next steps text and update the page with the results
    EvidenceSetDwrFacade.getNextSteps( this.evidenceSetId, function( response )
      {
        if ( response )
        {
          $( 'nextStepsContent' ).innerHTML = response;
        }
      }.bindAsEventListener( this ) );
  },

If it's plain text or served up by the server itself it should be the same everywhere, unless the server is providing different information. But if that ajax call can pull in more code then maybe that's where it's hiding from me.

But don't bother yourselves more on this. It's too much of a mess with not enough information. And it's probably either a caching thing or something weird they are doing on their end.

I'd really be interested in the actual time being returned for one client in the past (internal machine) versus another rooted in the present (external machine). That's what I'd be checking. You need to verify your external server isn't returning something insane, and the vendor's word means two things -- jack and shit.

Most likely scenario going on: The AJAX code is either returning JSON (likely), XML (less likely) data, or HTML (solid maybe) by way of a dynamic async grab ... there are some weirdo edges cases I'm excluding, but I assume no one is Rube Goldberging a system time call. However you process the response is pathological to your app.

$( 'nextStepsContent' ).innerHTML = response;

This makes it look like the HTML content of whatever nextStepsContent is just gets the response pasted in, which means HTML wins, although they could pass it as XML if it's particularly careful HTML. You should be able to open the developer tools in the browser o' your choice (F11, usually) and put a breakpoint on that line to freeze things and read the value of response. If you can catch their server returning an insane time, then you win. If it returns a proper time, then your client is haunted in some deeply disturbing/hilarious way.

[TPRJones]

Interesting. I will try these things tomorrow and report on the results.

[TPRJones]

Alright, using the Chrome console I can see the Ajax call. "response" goes from a null value to a line of text including the date and time built right in, pulled in right from the server. So unless the Ajax calls could fall afoul of some caching that doesn't appear to be affecting the rest of the page, then their servers are giving us weird results directly.

Thanks! I've never known about those debug tools in the browser. Sure would have made my recent foray into coding Java a bit easier.

[Malcolm]

Alright, using the Chrome console I can see the Ajax call. "response" goes from a null value to a line of text including the date and time built right in, pulled in right from the server. So unless the Ajax calls could fall afoul of some caching that doesn't appear to be affecting the rest of the page, then their servers are giving us weird results directly.

You got proof of their shitty response? Not bad.

Thanks! I've never known about those debug tools in the browser. Sure would have made my recent foray into coding Java a bit easier.

Java or Javascript?

[TPRJones]

Oh, sorry, Javascript. It's all javascript everywhere these days, it seems.

[Malcolm]

Oh, sorry, Javascript. It's all javascript everywhere these days, it seems.

Unfortunately.

[TPRJones]

Crap. Ajax is something that may cache. They have the code in there that instructs the client not to cache it, but in theory if our network is doing some caching that would ignore such settings and make them useless. My proof is less than iron-clad.