{"action":"created","issue":{"url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security/issues/92","repository_url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security","labels_url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security/issues/92/labels{/name}","comments_url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security/issues/92/comments","events_url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security/issues/92/events","html_url":"https://github.com/Arsenal21/all-in-one-wordpress-security/issues/92","id":332350157,"node_id":"MDU6SXNzdWUzMzIzNTAxNTc=","number":92,"title":"Let forbidden be forbidden - the status of wp_die() events","user":{"login":"karex","id":921474,"node_id":"MDQ6VXNlcjkyMTQ3NA==","avatar_url":"https://avatars2.githubusercontent.com/u/921474?v=4","gravatar_id":"","url":"https://api.github.com/users/karex","html_url":"https://github.com/karex","followers_url":"https://api.github.com/users/karex/followers","following_url":"https://api.github.com/users/karex/following{/other_user}","gists_url":"https://api.github.com/users/karex/gists{/gist_id}","starred_url":"https://api.github.com/users/karex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/karex/subscriptions","organizations_url":"https://api.github.com/users/karex/orgs","repos_url":"https://api.github.com/users/karex/repos","events_url":"https://api.github.com/users/karex/events{/privacy}","received_events_url":"https://api.github.com/users/karex/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-06-14T10:50:32Z","updated_at":"2018-07-22T14:35:27Z","closed_at":null,"author_association":"NONE","body":"There are some places, where the AIOWPS dies to prevent malicious requests and user actions, and these are handled with `wp_die`, but without the `$args` argument filled, and that yields a HTTP status code of 500, which pollutes the server's logs, and one might think that something is wrong, which is not the case.\r\n\r\nThese situations should return a 403 status code in my understanding.\r\n\r\nAn easy fix would be to specify status 403 when wp_die is called (maybe with a filterable constant). Additionally, I think it would be great to be able to filter these \"dies\", because e.g. one might want to redirect these requests instead of displaying errors. For this, a \"framing function\" for die events and a filter might be great, where we might be able to filter the actual function called in these \"die\" events.\r\n\r\nWhat do you think?"},"comment":{"url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security/issues/comments/406871180","html_url":"https://github.com/Arsenal21/all-in-one-wordpress-security/issues/92#issuecomment-406871180","issue_url":"https://api.github.com/repos/Arsenal21/all-in-one-wordpress-security/issues/92","id":406871180,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNjg3MTE4MA==","user":{"login":"karex","id":921474,"node_id":"MDQ6VXNlcjkyMTQ3NA==","avatar_url":"https://avatars2.githubusercontent.com/u/921474?v=4","gravatar_id":"","url":"https://api.github.com/users/karex","html_url":"https://github.com/karex","followers_url":"https://api.github.com/users/karex/followers","following_url":"https://api.github.com/users/karex/following{/other_user}","gists_url":"https://api.github.com/users/karex/gists{/gist_id}","starred_url":"https://api.github.com/users/karex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/karex/subscriptions","organizations_url":"https://api.github.com/users/karex/orgs","repos_url":"https://api.github.com/users/karex/repos","events_url":"https://api.github.com/users/karex/events{/privacy}","received_events_url":"https://api.github.com/users/karex/received_events","type":"User","site_admin":false},"created_at":"2018-07-22T14:35:27Z","updated_at":"2018-07-22T14:35:27Z","author_association":"NONE","body":"Yeah, true, there are different places where different HTTP status codes might be appropriate.\r\n\r\nWhat concerned me actually is where [Stop User Enumeration](https://github.com/Arsenal21/all-in-one-wordpress-security/blob/3a8874196ae704118cf1ab066190ce420dd7e2c6/all-in-one-wp-security/other-includes/wp-security-stop-users-enumeration.php) is implemented. Here a 403 would be preferable probably.\r\n\r\nOther places might need a review too. For example think the [locked out IPs](https://github.com/Arsenal21/all-in-one-wordpress-security/blob/c9c20fa453ace2e4c793f3baab9070d7edcc3e4d/all-in-one-wp-security/classes/wp-security-user-login.php) might have a status code of 403 or 404.\r\n\r\nI conclude this from [RFC 2616 10.4.4](https://tools.ietf.org/html/rfc2616#section-10.4.4), which says that 403 is for events when \"server understood the request, but is refusing to fulfill it.\", but if the server does not want to make the reason of the refusal available, then \"the status code 404 (Not Found) can be used instead.\""}}
{"actor":{"display_login":"karex"}}