Files
@ cec84c4675ce
Branch filter:
Location: kallithea/docs/index.rst - annotation
cec84c4675ce
1.3 KiB
text/prs.fallenstein.rst
tests: remove race condition in test_forgot_password
One in so many times, test_forgot_password failed with:
kallithea/tests/functional/test_login.py:427: in test_forgot_password
assert '\n%s\n' % token in body
E assert ('\n%s\n' % 'd71ad3ed3c6ca637ad00b7098828d33c56579201') in
"Password Reset Request\n\nHello passwd reset,\n\nWe have received a
request to reset the password for your account.\n\nTo
s...7e89326ca372ade1d424dafb106d824cddb\n\nIf it weren't you who
requested the password reset, just disregard this message.\n"
i.e. the expected token is not the one in the email.
The token is calculated based on a timestamp (among others). And the token
is calculated twice: once in the real code and once in the test, each time
on a slightly different timestamp. Even though there is flooring of the
timestamp to a second resolution, there will always be a race condition
where the two timestamps floor to a different second, e.g. 4.99 vs 5.01.
The problem can be reproduced reliably by adding a sleep of e.g. 2 seconds
before generating the password reset mail (after the test has already
calculated the expected token).
Solve this problem by mocking the time.time() used to generate the
timestamp, so that the timestamp used for the real token is the same as the
one used for the expected token in the test.
One in so many times, test_forgot_password failed with:
kallithea/tests/functional/test_login.py:427: in test_forgot_password
assert '\n%s\n' % token in body
E assert ('\n%s\n' % 'd71ad3ed3c6ca637ad00b7098828d33c56579201') in
"Password Reset Request\n\nHello passwd reset,\n\nWe have received a
request to reset the password for your account.\n\nTo
s...7e89326ca372ade1d424dafb106d824cddb\n\nIf it weren't you who
requested the password reset, just disregard this message.\n"
i.e. the expected token is not the one in the email.
The token is calculated based on a timestamp (among others). And the token
is calculated twice: once in the real code and once in the test, each time
on a slightly different timestamp. Even though there is flooring of the
timestamp to a second resolution, there will always be a race condition
where the two timestamps floor to a different second, e.g. 4.99 vs 5.01.
The problem can be reproduced reliably by adding a sleep of e.g. 2 seconds
before generating the password reset mail (after the test has already
calculated the expected token).
Solve this problem by mocking the time.time() used to generate the
timestamp, so that the timestamp used for the real token is the same as the
one used for the expected token in the test.
5f481e4e888b 5f481e4e888b 22a3fa3c4254 beb4cbf30d00 22a3fa3c4254 22a3fa3c4254 e71216a16853 e71216a16853 e71216a16853 2cbdbf55ed99 e71216a16853 2cbdbf55ed99 bdd1ddd05b7c 03bbd33bc084 03bbd33bc084 5f481e4e888b 03bbd33bc084 03bbd33bc084 2cbdbf55ed99 e71216a16853 2cbdbf55ed99 e71216a16853 e71216a16853 5f481e4e888b 5f481e4e888b 5f481e4e888b 5f481e4e888b 154becd92f40 5f481e4e888b 64b1a2320bcb d95ea48af67b e69d34136be5 57caeb60c52b 8075ec3d0233 8b8edfc25856 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 2898ea3ff76c 2bb5e9ee49fe e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 e71216a16853 2cbdbf55ed99 e71216a16853 2cbdbf55ed99 bb35ad076e2f bb35ad076e2f bb35ad076e2f bb35ad076e2f bbd499c7b55e 2bb5e9ee49fe bbd499c7b55e e71216a16853 beb4cbf30d00 beb4cbf30d00 e71216a16853 2cbdbf55ed99 bb35ad076e2f bb35ad076e2f bb35ad076e2f 8b8edfc25856 bb35ad076e2f 5262c498b3a0 9fd64dd2617d 5f481e4e888b fbbe80e3322b a60cd29ba7e2 5f481e4e888b 5f481e4e888b cc21a2b86a30 9472a0150bf0 5f481e4e888b a60cd29ba7e2 a60cd29ba7e2 a60cd29ba7e2 8b8edfc25856 | .. _index:
#######################
Kallithea Documentation
#######################
* :ref:`genindex`
* :ref:`search`
Readme
******
.. toctree::
:maxdepth: 1
readme
Administrator guide
*******************
**Installation and upgrade**
.. toctree::
:maxdepth: 1
overview
installation
installation_win
installation_win_old
installation_iis
installation_puppet
upgrade
**Setup and configuration**
.. toctree::
:maxdepth: 1
setup
administrator_guide/auth
administrator_guide/vcs_setup
usage/email
usage/customization
**Maintenance**
.. toctree::
:maxdepth: 1
usage/backup
usage/performance
usage/debugging
usage/troubleshooting
User guide
**********
.. toctree::
:maxdepth: 1
usage/general
usage/vcs_notes
usage/statistics
api/api
Developer guide
***************
.. toctree::
:maxdepth: 1
contributing
dev/translation
dev/dbmigrations
.. _virtualenv: http://pypi.python.org/pypi/virtualenv
.. _python: http://www.python.org/
.. _django: http://www.djangoproject.com/
.. _mercurial: https://www.mercurial-scm.org/
.. _bitbucket: http://bitbucket.org/
.. _subversion: http://subversion.tigris.org/
.. _git: http://git-scm.com/
.. _celery: http://celeryproject.org/
.. _Sphinx: http://sphinx.pocoo.org/
.. _vcs: http://pypi.python.org/pypi/vcs
|