Closed Trott closed 12 years ago
I agree that this is a possibly challenging side-effect, but I don't think we can have our cake and eat it too.
I'm going to go ahead and tag v1.3.00, but I'll leave this issue open for the time being. Let's discuss during the next core developer meeting.
One possible ambitious solution is to eliminate the cookies altogether. Much (all?) of the cookie content is actually unneeded. If nothing else, we should at least get rid of the unnecessary stuff to keep the payload small. Here's how I see it:
Even if we fail in this attempt to deal with this minor issue (and any other issues, major or minor) caused by the cookie/redirect stuff, pretty much all the things we'd be doing are things we ought to be looking at anyway.
This makes sense to consider for 2.0 - we can think about a strategy that gets rid of these completely.
However, as we at least have MWF 1.4 still coming down the current vein, they need to stay for the time.
The suggestion Ed and I put together and approved by Core Dev meeting today is to add a timestamp to no_server_init
parameter.
If we go the timestamp route, it is probably worth mentioning in documentation that all servers should be sync'ed to an NTPD server or something similar since a timestamp that is off by a few minutes could result in endless redirect looping....
For passthru.php, the timestemp would be both set and ready by the MWF server, so it wouldn't need to be synced unless some institution were running multiple MWF servers and load balancing on a request-by-request basis.
However, there is indeed a clock skew issue for the local refresh case. If I reload via Javascript, then the GET parameter is defined by logic on my computer, not on the framework server. This makes the logic dependent on a sync between my machine and the framework server. One alternate approach would be to actually pass a timestamp into the Javascript as a hardcoded variable - but I need to think over the caching case here a bit more first.
I'm going to close this without rolling out the timestamp fix. It makes it possible to end up in an infinite loop in theory, whereas the counterpoint is simply one screen displayed as basic rather than full - the latter is definitely less invasive.
The no_server_init stuff has some bad potential side effects that are coming out of testing.
The first time you go to a site, you get a ?no_server_init tacked on to the end of your URL.
If you cut and paste that URL to send to someone else, saying "Hey, check out this awesome site!", and they put it in their browser, they end up with the basic site rather than the full site.