Timeline for Banned user tries to log in − show a “Banned” message or a generic “Cannot log you in”?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 23, 2015 at 15:26 | comment | added | corsiKa | @Pacerier But those are in place before you could even reach the database to determine if it's the same person. That is done at the IP layer. Such a request would never get to business code that even cared about your cookie to determine if you were banned or not. | |
| Nov 22, 2015 at 20:39 | comment | added | Pacerier |
[cont] Point being, you mentioned that "someone will somewhere forget to put" in the check, and my point is that the CheckLimit() checks are already in place. They must already be in place otherwise there would have been a security bug because without the function check, users would be able to do unlimited actions. We need only to add the extra code within the CheckLimit() function one time.
|
|
| Nov 22, 2015 at 20:38 | comment | added | Pacerier |
@corsiKa, No I mean it's precisely because of this reason. Because the user/hacker could have built his own custom UI that sends direct network requests, therefore each and every user action must have a function CheckLimit() which denies the request if there there are too many requests previously. CheckLimit() is done even for simple stuff like loading a webpage. (for example just try to spam Google or even SE, you'll get a few minutes of network ban whenever you had requested to load too many pages within a fixed amt of time).
|
|
| Nov 13, 2015 at 20:48 | comment | added | corsiKa | @Pacerier That is at a layer completely unrelated. And you're absolutely right about going around the UI. There's nothing you can (or really should) do about such things, since your logic should be consistent anyway. | |
| Nov 13, 2015 at 11:49 | comment | added | Pacerier | @corsiKa, The checks are crucial for rate limiting users to actions. If you simply fetch for a user cookie, that user can do unlimited actions as fast as his network can handle (or your server CPU can). Which can easily be 1000 actions per second using a bot. Note that the user can easily bypass the game UI since the server would also see network requests and not be able to differentiate them without extra checks. | |
| Nov 8, 2015 at 18:46 | comment | added | corsiKa | @Pacerier Seems wasteful - someone will somewhere forget to put that at the top of one of the services. Instead, the logic is simply: check the login cookie, fetch the user for that login cookie. Since I got a user, that user can do the action. Without a user, well you can't do the action. This is a common design paradigm in games. | |
| Nov 8, 2015 at 2:01 | comment | added | Pacerier | @corsiKa, Well, if the app is indeed designed properly, "check everywhere for someone being banned" could be as simple as one function that is reused everywhere. You would need functions to do checks anyway to prevent "unlimited actions" or spam. Stuff like vote limit, post limit, search refresh limit, page load limit, and etc. | |
| Nov 7, 2015 at 20:36 | comment | added | JBentley | @corsiKa There is no confusion, I was simply disagreeing with you. You made a generalised statement ("it is easier to ....") and I gave a counter using a specific example, being the same example the OP uses. Even this answer uses a forum-like example with similar access controlled privileges, so it is not necessary to extent the context of your comment to the question to disagree with it. In the case of Stack Exchange, it is easier from a design point of view to ban activities rather than logins, because the entire site is already geared towards that. | |
| Nov 7, 2015 at 18:49 | comment | added | corsiKa | My comment was not about the question. If I wanted to comment on the question, I would have commented on the question. My comment was on nicael's answer, where he says "So, why restrict logging in at all?" and my comment was a rebuttal to that rhetorical question. I don't see where the confusion lies... | |
| Nov 7, 2015 at 17:11 | comment | added | JBentley | @corsiKa The OP 's question is about a forum specifically, as well as the general case. | |
| Nov 7, 2015 at 17:10 | comment | added | corsiKa | Sure, in the context of a forum. There are many types of apps that work absolutely nothing like forums. Most mobile apps, for example. | |
| Nov 7, 2015 at 16:55 | comment | added | JBentley | @corsiKa In the context of a forum, there is typically some kind of tiered privilege system. Site admin, moderator, confirmed/unconfirmed email address, etc. So unless the forum is extremely basic, there has to be a differentiation between different logins and what they are allowed to do. Since you have that already, it isn't unreasonable to use that system to deal with banned users, too. It has the added benefit of taking care of users who were already logged in at the time of being banned, which you'd have to address separately in the "all logins can do anything" paradigm. | |
| Nov 5, 2015 at 20:29 | comment | added | corsiKa | It is easier (from a design perspective) to assume that anyone who can log in can also use the basic functionality of the app. By preventing logging in, you don't have to check everywhere for someone being banned. Not saying I support that thought process, just saying that's a model that some people use when designing their app. | |
| Nov 5, 2015 at 18:25 | history | answered | nicael | CC BY-SA 3.0 |