Change Details

When an IP address is blocked with the option to include logged-in users (e.g. hardblocked), the block includes a cookie block. The most common case where this comes up is when a user is using an open proxy (many of these IP addresses are hardblocked), and then forgets to turn it off. They often realize it after attempting to edit, and once they turn it off, they find that they are still blocked. The block message will only include an IP range that the user is likely no longer using. This makes troubleshooting on the user's end complicated - and makes helping the user more difficult. Yes, it is possible to set $wgCookieSetOnAutoblock to prevent cookie blocks wholesale, but they are generally useful for other usecases. It would be very helpful to have the option to exempt hard IP blocks from triggering cookie blocks at the time that the block is made/modified. Related tickets: T207609 T236955

When an IP address is blocked with the option to include logged-in users (e.g. hardblocked), the block includes a cookie block. The most common case where this comes up is when a user is using an open proxy (many of these IP addresses are hardblocked), and then forgets to turn it off. They often realize it after attempting to edit, and once they turn it off, they find that they are still blocked. The block message will only include an IP range that the user is likely no longer using. This makes troubleshooting on the user's end complicated - and makes helping the user more difficult. Yes, it is possible to set $wgCookieSetOnAutoblock to prevent cookie blocks wholesale, but they are generally useful for other usecases. It would be very helpful to have the option to exempt hard IP blocks from triggering cookie blocks at the time that the block is made/modified. Related tickets: {T207609} {T236955}

When an IP address is blocked with the option to include logged-in users (e.g. hardblocked), the block includes a cookie block. The most common case where this comes up is when a user is using an open proxy (many of these IP addresses are hardblocked), and then forgets to turn it off. They often realize it after attempting to edit, and once they turn it off, they find that they are still blocked. The block message will only include an IP range that the user is likely no longer using. This makes troubleshooting on the user's end complicated - and makes helping the user more difficult. Yes, it is possible to set $wgCookieSetOnAutoblock to prevent cookie blocks wholesale, but they are generally useful for other usecases. It would be very helpful to have the option to exempt hard IP blocks from triggering cookie blocks at the time that the block is made/modified. Related tickets: {T207609} {T236955}