Access date/time of request.

[Rémy Sanchez]

Hi,

I often work with time-sensitive tokens. By example, you give to the client a token that is valid during 1h and authenticates them during this time.

Now, suppose that someone makes a request just a few milliseconds before the expiration of the token. Maybe that the time is checked twice in two different locations of the code and the second check will be false while the first check was true. Maybe this will create inconsistent data with things happening after the expiration of the token while it shouldn't.

In essence, a request is conceptually instant while in fact it stretches through time a little bit.

My usual practice, depending on the project, is either I do something like fixed_now = now() and then pass it along all my calls or either I create a middleware that injects that time in the request object so I can fetch it from anywhere.

While this works, I'm thinking that it could be beneficial for Django to have a standard way of dealing with this. Indeed, this would allow various libraries to build on it, I'm thinking notably of DRF that could detect the activation of the feature and then use the request date instead of the actual date for things like auto(_add)?_now.

I would propose the following implementation:

def view(request: HttpRequest) -> HttpResponse:
    return render(request, "date.html", {"now": request.now()})

With request.now being something like that:

def now(self):
    try:
        return META['FIXED_NOW']
    except KeyError:
        return now()

There would be a middleware in charge of feeding META['FIXED_NOW'] with the right value, that is packaged with Django but that is not enabled by default. Maybe even several middlewares: one that watches the clock, one that gets the time from the reverse proxy, etc.

To summarize, time-sensitive operations conceptually require to consider that requests are instant, this is why I'm proposing a way to embed a fixed date/time into the request so there is a standard way of getting the date of the request. The implementation would be totally optional and would have no side-effects on people not enabling it. While this is easily solved with third-party code, standardization would mean that other tools could start relying on it.

If this strikes an interest, I would gladly do the implementation of that feature.

Please tell me what you think.

Thanks,
Rémy

[Mariusz Felisiak]

Thanks for this ticket, however IMO this is quite niche. Moreover I don't think that using a non standard header is a proper approach because it will create a big security issue. You can start a discussion on DevelopersMailingList if you don't agree.