Link to the commit introducing the CheckUserBan middleware
authorTim Düsterhus <duesterhus@woltlab.com>
Fri, 21 Oct 2022 13:25:11 +0000 (15:25 +0200)
committerTim Düsterhus <duesterhus@woltlab.com>
Fri, 21 Oct 2022 13:25:11 +0000 (15:25 +0200)
docs/migration/wsc55/php.md

index a121624bf97d36cd6d5785627e9ba8d7658f8259..2c5be168fe904d71066e68cb75ca19ff371bb593 100644 (file)
@@ -31,7 +31,7 @@ To achieve a clean separation this type of request-specific logic will increment
 
 An example of this type of request-specific logic that was previously happening during application boot is the check that verifies whether a user is banned and denies access otherwise.
 This check is based on a request-specific value, namely the user’s session which in turn is based on a provided (HTTP) cookie.
-It is now moved into the [`CheckUserBan` middleware](https://github.com/WoltLab/WCF/blob/master/wcfsetup/install/files/lib/http/middleware/CheckUserBan.class.php).
+It is now [moved into the `CheckUserBan` middleware](https://github.com/WoltLab/WCF/commit/51154ba3f8f1d09b54560d5d1933f9053ef409cb).
 
 This move implies that custom scripts that include WoltLab Suite Core’s `global.php`, without also invoking `RequestHandler` will no longer be able to rely on this type of access control having happened and will need to implement it themselves, e.g. by manually running the appropriate middlewares.