Expired Source Interface session causes server error on new session

[eloquence]

Description

Creating a new codename after a session has expired causes a server error.

Steps to Reproduce

1. Visit the codename generation page (/generate) but do not press 'Submit Documents'
2. Wait for the session to expire
3. Press 'Submit Documents'

Diff to force session expiry at 1 minute:

diff --git a/securedrop/source_app/__init__.py b/securedrop/source_app/__init__.py
index d2679b737..60df38ece 100644
--- a/securedrop/source_app/__init__.py
+++ b/securedrop/source_app/__init__.py
@@ -148,9 +148,7 @@ def create_app(config):
             flash(Markup(msg), "important")
 
         session['expires'] = datetime.utcnow() + \
-            timedelta(minutes=getattr(config,
-                                      'SESSION_EXPIRATION_MINUTES',
-                                      120))
+            timedelta(minutes=1)
 
         # ignore_static here because `crypto_util.hash_codename` is scrypt
         # (very time consuming), and we don't need to waste time running if

Expected Behavior

A new codename is generated or an appropriate error message is shown.

Actual Behavior

The Source Interface displays:

Server error
Sorry, the website encountered an error and was unable to complete your request.

[eloquence]

See also the similar #4458 which may have the same root cause.

I've only reproduced this once as I haven't mucked around with forcing session expiry yet.

[redshiftzero]

After forcing session expiration to be one minute, I can't reproduce this - are there any additional STR?

[eloquence]

Thanks for the repro attempt, will try a clean repro as well and document exact steps here if successful.

[eloquence]

One way to get the error appears to be to wait with attempting to create the codename until the expiry of the session.

I've updated the issue accordingly, and added the diff I used for forcing session expiry. Here's the traceback from the dev env:

KeyError

KeyError: 'codename'
Traceback (most recent call last)

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 2309, in __call__

    return self.wsgi_app(environ, start_response)

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 2295, in wsgi_app

    response = self.handle_exception(e)

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1741, in handle_exception

    reraise(exc_type, exc_value, tb)

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 2292, in wsgi_app

    response = self.full_dispatch_request()

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1815, in full_dispatch_request

    rv = self.handle_user_exception(e)

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1718, in handle_user_exception

    reraise(exc_type, exc_value, tb)

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1813, in full_dispatch_request

    rv = self.dispatch_request()

    File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1799, in dispatch_request

    return self.view_functions[rule.endpoint](**req.view_args)

    File "/home/erik/Code/securedrop/securedrop/source_app/main.py", line 56, in create

    session['codename'])

    File "/usr/local/lib/python2.7/dist-packages/werkzeug/local.py", line 377, in <lambda>

    __getitem__ = lambda x, i: x._get_current_object()[i]

    File "/usr/local/lib/python2.7/dist-packages/flask/sessions.py", line 83, in __getitem__

    return super(SecureCookieSession, self).__getitem__(key)

    KeyError: 'codename'

[eloquence]

I can reproduce this behavior in develop, on the 0.13.0 release branch, and at commit c24f61f (prior to fix for #4361).

[eloquence]

There also appears to be something else going on. I tried it again on my prod instance (without code changes to force the expiry), and reproduced the bug described here (got a server error). I then clicked on the logo, and was able to generate a new codename. After logging out and attempting to generate a codename again, I got a new server error. Subsequent attempts succeeded.

Just making a note of this behavior here to investigate further.

Update: Have not been able to repro this in dev env. Will keep an eye on it as we resolve the main issue described here.