Unauthenticated AJAX requests are redirected to login page

[andreyv]

Consider this situation:

1. User logs in to CWS
2. Contestant interface is left open in the browser for a long time
3. Authentication cookie expires
4. The open web page continues to poll notifications

In this case each notification request will be redirected to the login page, which the browser will follow and get a HTTP 200 response. Example:

2018-12-07 23:58:19,513 - INFO [Contest,0 33 web::log_request] 302 GET /test/notifications?last_notification=1541246386.704781 (10.0.2.2) 10.87ms
2018-12-07 23:58:19,531 - INFO [Contest,0 34 authentication::_authenticate_request_from_cookie] Unsuccessful cookie authentication: no cookie provided
2018-12-07 23:58:19,536 - INFO [Contest,0 34 web::log_request] 200 GET /test?next=%2Ftest%2Fnotifications%3Flast_notification%3D1541246386.704781 (10.0.2.2) 10.64ms

~I'm not sure if this would be considered a bug. Feel free to close this issue if it's not.~

[andreyv]

There are more such requests, for example, submission status or test status, also there are similar cases in AWS. Basically, those requests for which refresh_cookie is set to false.

It should be enough to replace the @tornado.web.authenticated decorator on relevant handler methods with code that simply returns HTTP 403. Or rename refresh_cookie to is_manual_request and write a decorator that takes this into account, but otherwise behaves like @tornado.web.authenticated.

[andreyv]

More info on a similar problem with submission details. Steps to reproduce (in multicontest mode):

1. Set CWS cookie_duration to a short value, e.g., 60
2. Log in to the contest
3. Open the submissions page for some task
4. Wait until the cookie expires
5. Click "details" on a submission

Actual result: the login page briefly flashes in the modal submission details element, then the browser navigates to /<contest>/tasks/<task>/<contest> and shows either a 404 or 405 error page depending on contest name.

Sample access log:

2019-08-30 11:39:43,994 - INFO [Contest,0 26 authentication::_authenticate_request_from_cookie] Unsuccessful cookie authentication: no cookie provided
2019-08-30 11:39:44,002 - INFO [Contest,0 26 web::log_request] 302 GET /test/tasks/Sum/submissions/2/details (10.0.2.2) 14.78ms
2019-08-30 11:39:44,071 - INFO [Contest,0 27 authentication::_authenticate_request_from_cookie] Unsuccessful cookie authentication: no cookie provided
2019-08-30 11:39:44,076 - INFO [Contest,0 27 web::log_request] 200 GET /test?next=%2Ftest%2Ftasks%2FSum%2Fsubmissions%2F2%2Fdetails (10.0.2.2) 17.27ms
2019-08-30 11:39:44,214 - WARNING [Contest,0 28 web::log_request] 404 GET /test/tasks/Sum/static/jq/jquery-1.7.1.min.js?_=1567154384133 (10.0.2.2) 4.52ms
2019-08-30 11:39:44,226 - WARNING [Contest,0 29 web::log_request] 404 GET /test/tasks/Sum/static/css/bootstrap.css (10.0.2.2) 2.88ms
2019-08-30 11:39:44,238 - WARNING [Contest,0 30 web::log_request] 404 GET /test/tasks/Sum/static/cws_style.css (10.0.2.2) 2.23ms
2019-08-30 11:39:44,332 - WARNING [Contest,0 31 web::log_request] 404 GET /test/tasks/Sum/static/favicon.ico (10.0.2.2) 2.98ms
2019-08-30 11:39:44,370 - WARNING [Contest,0 32 web::log_request] 404 GET /test/tasks/Sum/static/js/bootstrap.js?_=1567154384337 (10.0.2.2) 1.06ms
2019-08-30 11:39:44,461 - WARNING [Contest,0 33 web::log_request] 404 GET /test/tasks/Sum/static/cws_utils.js?_=1567154384441 (10.0.2.2) 6.51ms
2019-08-30 11:39:44,605 - INFO [Contest,0 34 authentication::_authenticate_request_from_cookie] Unsuccessful cookie authentication: no cookie provided
2019-08-30 11:39:44,632 - WARNING [Contest,0 34 web::log_request] 405 GET /test/tasks/Sum/test (10.0.2.2) 29.94ms

Observe the interesting additional requests after requesting the login page in this case. The 404 requests are from the browser rendering the login page inline and requesting resources relative to the current URL (/test/tasks/Sum/submissions). However, I don't yet understand where the 405 request originates.

Considering this case, the above is_manual_request should actually be is_xhr, i.e., XHRs shouldn't be redirected to the login page and instead should get HTTP 403 if the login cookie expired.