Forums
Sacha received custody of a legacy Python API, and was tasked with implementing a fresh version of it.
He focused on authentication first. The existing API used JSON web tokens that, for some reason, never expired. Assignments like expiration=86400 and expiration=3600 were littered throughout the code, but seemed to go ignored.
It didn't take long to track down the token generating code and figure out the tokens' source of (near) immortality:
expInTS = calendar.timegm(datetime_tz.now().timetuple())
expiration_seconds = 86400
expiration = (datetime_tz.now() + datetime.timedelta(seconds=expiration_seconds))
return {'status': True,
"auth_token": user.generate_auth_token(expiration=expInTS),
'code': code,
"token_expiration": expiration.strftime('%Y-%m-%dT%H:%M:%S'),
'user': user.to_json()}, 200
Several expiration-related variables are set up at first, and even the original coder seemed to have gotten confused by them. When generating the token, he or she used expInTS for the expiration value instead of expiration. The problem is that expInTS is set to the current Unix timestamp—which is the number of seconds that have transpired since January 1, 1970.
The slip was confirmed when Sacha looked at a token header:
{
alg: "HS256",
exp: 2977106874,
iat: 1488553437
}
iat (issued at) shows the Unix timestamp when the token was created. The timestamp was then added to itself, resulting in the timestamp for expiration shown in exp. That timestamp corresponds to May 4, 2064, a date by which most of us will be dead or retired.
Profound, yes, but not exactly desirable. Sacha adjusted the expiration value to 86400 seconds (1 day), then moved along.
[Advertisement]
BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!