You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now, let's say the uat.Timestamp value is for example "2014-07-25 18:00:00". The "+" equation (uat.Timestamp + uat.Lifetime) results in an integer like this for a lifetime value of "60":
20140725180060
So, it just converts the date string "2014-07-25 18:00:00" into an integer "20140725180000" and adds the lifetime value of "60" to it.
Therefore, the actual comparison done by MySQL is equal to this query:
SELECT20140725180060>='NOW()'
It compares the first integer into string "NOW()". And the "NOW()" string evaluates always to zero in its integer conversion, so this statement is always true.
It makes the tokens valid forever.
The text was updated successfully, but these errors were encountered:
Noticed this line of code when debugging our SSO implementation:
vanilla/library/core/class.authenticator.php
Line 272 in 55db7e6
(I picked a specific commit tree so that the code reference does not change.)
I believe this comparison makes the tokens valid forever.
The comparison that I checked from the MySQL logs looked like this:
Now, let's say the uat.Timestamp value is for example "2014-07-25 18:00:00". The "+" equation (uat.Timestamp + uat.Lifetime) results in an integer like this for a lifetime value of "60":
20140725180060
So, it just converts the date string "2014-07-25 18:00:00" into an integer "20140725180000" and adds the lifetime value of "60" to it.
Therefore, the actual comparison done by MySQL is equal to this query:
It compares the first integer into string "NOW()". And the "NOW()" string evaluates always to zero in its integer conversion, so this statement is always true.
It makes the tokens valid forever.
The text was updated successfully, but these errors were encountered: