Welcome Guest, Not a member yet? Register   Sign In
How to awoid admin collision in CMS?
#1

[eluser]SPeed_FANat1c[/eluser]
Hi,

in my website I have multiple admin accounts (you can create as many admins as you want). I want to make that if one of the admins is connected, then the other would not be able to connect.

So when a user with status admin tries to connect the funtion 'is_admins_logged_in' would be executed.

If I want to chek is user logged in I do this:
Code:
function is_logged_in()
    {
        $is_logged_in = $this->session->userdata('is_logged_in');
        if(!isset($is_logged_in) || $is_logged_in != true)
        {

            return FALSE;
        }        
        else return TRUE;
    }
But with $this->session->userdata you can't check if the user with name 'admin' or with id = X is logged in. Any thoughts how to check if the particular user is logged in?
I am storing session in the database.
#2

[eluser]Flemming[/eluser]
you could store the current logged-in user name or email address in a DB table and query that whenever you call your login method, to make sure that someone isn't already logged in.

The main problem I forsee is that you need to make 100% sure that when a user logs out, the 'logged_in' DB record gets deleted.
#3

[eluser]WanWizard[/eluser]
This is the way ExiteCMS does it.

It also stores an expiry timestamp, which is equal to the session expire timestamp. As long as the session is valid, we consider the user logged in.
Queries on the 'online' table exlude expired results, expired records are periodically deleted in the same way the session library does it.

This approach has a risk. As the timeout is configurable, an administrator could set the timeout to 1 month, login, kill the browser, and go on an extended vacation. And all the time all other administrators are locked out.

I think you have to ask yourself what it is that you are trying to protect other admins against, i.e. why can't you allow simultanous logins? A web application should support multi-user access, collisions should be dealt with in every screen...
#4

[eluser]SPeed_FANat1c[/eluser]
I'll try to explain.

There is admin1 and admin2, both opened the same page - advertising administration. You can see in the link how it looks: http://img295.imageshack.us/img295/8010/18483564.jpg

WHEN I SAY SECOND AD I MEAN IN SECOND POSITION, DON'T LOOK AT THOSE NUMBERS I MADE WITH PAINT Smile

admin1 moves up the middle ad. So the second ad becomes third and the third becomes second.

Of course admin2 nothing knows and no changes see. Then admin2 wants to move third ad up. What happens: third ad moves straight to the first position because actually it was not third anymore after the admin1 already moved it up - it was second (in the database).

Ok, admin1 wants to move up the same ad once again because he see it is in second position. And then there is error - it is imposible to move up that ad because it actually is at the top after admin two moved it.

jQuery gets an error and doesn't put this add anywhere, so admin1 sees only 4 ads now.

This is probably dificult to understand how all that goes without seeing it but it is not difficult to understand that it goes the not the way I would like Smile

I could add a check when moving - if it is possible at all to move it up to at least not get an error, alert to admin that it is not posible to move it up or down. When it would be possible without errors - the application still would not act as admins expect - like I explained earlier.

I also could reload all ad pictures and positions in database on every move up or down. This is only solution I can imagine now. Of course it would be not so bad for this site - not much traffic those adds use and there will not be 100 admins Smile

It looks I answered to my own question while writing this post Smile But it would be interesting to know how do you solve the same problem?
#5

[eluser]Flemming[/eluser]
here's a really simple suggestion just right off the top of my head (usually the worst type!)

admin number 1 logs in and he/she gets their user_id set into their userdata_session

admin number 2 logs in and same thing - userdata gets set.

admin number 1 goes to /your_controller/method that you DONT want 2 people to access at once, so

record gets written to DB with admin user_id and timestamp. every time they do any action within this controller the timestamp gets updated

admin number 2 goes to /your_controller/method that you DONT want 2 people to access at once, so

you check the DB and if the timestamp there is more than n minutes old they're allowed to access that controller. If the timestamp is less than n minutes old AND admin number 2 is NOT the owner of that DB record, you popup a lightbox/fancybox message to tell them the admin for this section is currently being used by someone else, please try again in n minutes.

I guess it's very similar to what WanWizard was proposing!
#6

[eluser]WanWizard[/eluser]
In a stateful environment these kind of issues are relatively easy to deal with.

The problem with PHP is that it's a stateless environment, within a session, and between sessions. There is no built-in mechanism to deal with multi-user aspects.

Most applications check before doing an update if the data their they are about to update is still the same. The perferred way of doing that is with a timestamp in each table. When you do an update, add the timestamp of the retrieved record as part of the where clause ('... AND timestamp = $timestamp'). If affected_rows() = zero, no record was updated, which most likely was a timestamp mismatch (I hope your application deals with other anomalies as well?). So you can inform the user that in the meantime someone else has updated the information, and reload the form with the updated data from the database.

Some people use locks on tables or rows, some self-designed locking mechanism (p.e. using files), and/or record a state (a lot of them with ASP background, using application memory) in the database. I find this very dangerous, since it could cause deadlocks or lock you out of parts of your application (because the guy who locked it went to get some lunch while the edit form was still open).
#7

[eluser]SPeed_FANat1c[/eluser]
Quote:Most applications check before doing an update if the data their they are about to update is still the same. The perferred way of doing that is with a timestamp in each table. When you do an update, add the timestamp of the retrieved record as part of the where clause (’... AND timestamp = $timestamp’)

I like this. For simplicity I update timestamps for every row in the table.

But there is a problem. There are two updates - the position of moved up ad and position of moved down ad. admin1 updates position of moved up ad and then admin2 reads the table and writes timestamps to it. admin1 can't update the position of moved down ad anymore.

Of course it is extremely unlikely but possible.

There is something to complicated for such simple website :|




Theme © iAndrew 2016 - Forum software by © MyBB