I bet it does! This is a standard approach, presented by majority of tutorials dealing with authentication and authorisation. Some of them go as far as to send authorisation flags and clear-text password forth and back within the cookies.

Oversimplified tutorials are just a tutorials, but real-life, production systems belong to the other realm. At least they should. But it happens, that such a tutorial-style algorithm sneaks in, in an almost unchanged form, into the service otherwise perfectly designed and implemented. It sits silently there, until the critical situation develops. Then it surprisingly blows up, with its crappyness unfurled to the full extent.

The system

Quite lot of data, many users, almost twenty thousand lines of perfectly structurized code, plus libraries. Well designed, and even better implemented system. When I open its scripts for edition, I always pay respect to the engineers and programmers who designed and wrote it. (Its price was also impressive, but let's leave that for another story.)

The incident

Due to the so called human factor, one day an urgent need appear to limit access rights of the group of users (let's call them moderators).

The system provides in the administration panel a relevant form, and deals perfectly with the data set up there. The problem lays in the logic (or rather lack of it) in this part of the application. I mean the following:

• access rights are checked (and granted) only once, during the log-in process. Then they are remembered forever (or at least till the end of session), so…
• …switching on and off various account settings has no influence on the effective rights of the person already logged in;
• there is no forced log-off mechanism implemented (it would be brutal, but effective way to re-set grants);
• even worse: moderators can further grant the moderation right, which is an obvious invitation to play follow the rabbit game…

The action

The situation should be put back under the firm control, before revolted moderators do any harm.

Possibilities in the current system are: either disconnecting it, changing accounts' rights and clearing all sessions stored on the server, or a prolonged war on the administrative backend, and applying social manipulations aimed to convince currently logged-in moderators to re-login.

The third solution is to fix the problem. Obviously, messing with the grants processing code under the time pressure and on a live system is looking for troubles. But the entire situation is a problem itself already, so hot-fix seems to be the most sane approach anyway.

The patch

From the efficiency point of view, verifying rights on every page load and every AJAX call would be questionable. But, as shown in the overview above, it is sometimes necessary.

In this particular case the following was done:

• a comparation of the key access rights the session claims to have, with the current rights read from the database. In case the difference is detected, the session is destroyed and the user is logged off.
• after that, all accounts of the rebel moderators were swept off.

Situation seems to be under control

It looked like that, but… The human factor can not be overestimated. A few hours after applying the patch, the new moderator accounts popped up in the system. How is that? At least one of the remaining, unsuspected accounts, was shared by a few users. And at least one of them started to create new accounts, granting them extended privileges.

The second patch

Obviously, it should not be actually any patch, but the logic implemented in the very core of the system. But it is better to be done late, than never.

• in the mechanism of the account editing, the feature of further granting the moderation privilege was removed;

• another privilege role has been added: a manager. This access flag will be since now required in order to change moderation privilege on the another account.
  Needless to say, for the time being nobody is granted with it.

Conclusions

1. Even the perfect - from the programmer's point of view - system can contain logical flaws.

2. Crisis, or the incident, is the issue that should be solved in advance.

The case description is deliberately altered in order to not reveal the identity of the service described.

Illustration: unknown Netherlandish artist in a manner of Hieronymus Bosch (1450-1516) and Pieter Bruegel the Elder (1526/30-1569): Christ driving the Money-lenders from the Temple.