Print

 

1.  Description

‘Logged in users’ is a normal Sheer UI portlet. Its purpose is to list the Users that are logged in to the Sitecore Client at the moment. After the package installation, you should open the Content Editor, switch to the Overview mode and add the portlet using the ‘Add content’ button of the Portal pane. It is necessary to press the Refresh button from time to time in order to be up to date with the Users in the system. You can also modify User settings by opening the Security Editor for the chosen User (by double clicking  the User).

2.  Installation Guide

The ‘Logged in Users’ portlet is distributed as a standard Sitecore package; therefore in order to start using it, you should install the package. Please refer to the ' Installing Modules and Packages ' article if you are not familiar with the Sitecore Packager. After the package installation, please restart the Sitecore Client.

 

The Readme step of the installation wizard provides a list of files and Items installed and thus provides information needed to uninstall this portlet.

 

IMPORTANT NOTE: Although the web application server restarts after any modifications of the web.config file, the information about the logged in Users is stored in a cookie. Therefore, in order to ensure complete information about the Users logged in to Sitecore, please re-log in after installing the portlet.

 

3.  User Manual

Once you have successfully installed the package and restarted the Client, open the Content Editor, switch to the Overview Viewer and select Add content in the Portal pane. The portlets displayed by default in the Overview Viewer have the Default checkbox checked in the appropriate Item in the Core database. The Default checkbox is not checked for the ‘Logged in Users’ portlet, therefore you need to open the portlet manually.

 

The ‘Logged in Users’ portlet provides you with information about Users that are currently logged in to the Sitecore CMS system. It has a rather simple and obvious user interface, and you shouldn’t face any difficulties when using this portlet.

 

The portlet displays a list of all Users who are logged in. They are represented in the detailed view, showing the additional information about the User (domain, email and content language) if this information has been specified for the User:

 

 

You can modify security permissions for a chosen User from the portlet. To do this double click a certain User, and the Security Editor for this User will open:

 

 

Note : To update the list of Users, press the Refresh button from time to time – the list will be refreshed to reflect the recently logged in/out Users.

 

There is a possibility to ‘kick’ other Users if you are Administrator.  Kicking a user logs them off the Sitecore Client. To do this click the appropriate button in the main menu. If you are not Administrator, you’ll be notified that non-administrators can’t manage Users. Also, you are not allowed to kick yourself, as this would make no sense. The kick option has an interesting and unusual feature, since it is based on the Sitecore common security model. For further information refer to the Architectural notes section.

 

4.  Architectural Notes

The internal Users’ management is controlled by the DomainAccessGuard class. It has the Kick() method, which actually removes the User from the list of logged in Users (out of the system). Thus, the next request the User makes to the server, that is opens the Content Editor, should redirect him to the login page. In reality, this doesn’t seem to happen: the User continues to stay logged into the system. The reason can’t be traced intuitively. When the kicked User tries to access a resource, DomainAccessGuard searches through the free licenses left, and if there are free ones, it logs the User in without any problems and notifications. So, the kick functionality has no visible effects when there are free licenses in the system.  

One more example: Let’s consider that you have 10 simultaneous Users allowed and all of them are logged in. When the 11-th User tries to log in, he is refused access to the Client. In this case, Administrator can kick one of the logged in Users (on his own wish), and the 11-th User will log in successfully. Finally, when the kicked User makes any activity which requires postback to the server, he’ll be immediately redirected to the login page.