Middleware which tracks the currently visited contest and stores it
- oioioi.contests.middleware.activate_contest(request, contest)¶
- class oioioi.contests.middleware.CurrentContestMiddleware(get_response)¶
Middleware which tracks the currently visited contest and stores it to be used in other parts of the current contest mechanism.
It is assumed that all contest-specific url patterns are defined in the
contest_patternsvariable in each module’s urlconf. These patterns are extended with non contest-specific patterns defined in the
urlpatternsvariable and then used to generate URLs prefixed with a contest ID (thus the non contest-specific URLs come in two versions, with and without a contest ID prefix). If a request matches a contest ID-prefixed URL and the ID is valid, the contest becomes the current contest. If the ID is not valid, a 404 Not Found is generated.
After a contest becomes the current contest, the corresponding
Contestinstance is available in
request.contest. In addition to that, our custom
reverse()function automatically prefixes generated URLs with the contest’s ID if appropriate.
settings.CONTEST_MODE, the administrator may decide that users should, if possible, be forcibly put into a contest. Then, if there is no contest ID in a request’s URL, but the URL also comes with a contest-specific version and a contest exists, a redirection is performed to one of the existing contests. Which one it is is determined by the following algorithm:
If last contest is saved in session, this value is used.
If the session value is not available or invalid,
If not set, the most recently created contest will be chosen.
URL patterns may be explicitly defined as requiring that no contest is given using the
noncontest_patternsvariable in each module’s urlconf. Again, using
settings.CONTEST_MODE, the administrator may decide that if a contest is available, users cannot access those URLs. Trying to access them then generates a 403 Permission Denied unless one is a superuser.