I'm working with Sitecore 8 Update 2.
I'm looking for a way to get some statistics on how many sitecore users are logged in ( over time, not just right now).
Mainly i would like to see if the actual amount of people working on the system is close to the maximum amount of users allowed by the license. Otherwise a company might be seriously overpaying.
Is there already an out of the box solution or a module available for this ?
If you visit this page:
<your-domain>/sitecore/client/Applications/LicenseOptions/KickUser
It will give you a list of all the currently logged in CMS users. That page is a SPEAK application and has a datasource called ActiveUsersDataSource. In the code, this datasource uses the DomainAccessGuard.Sessions property to get a list of all the sessions.
So if you just want a list, the KickUser page should be enough. If you want to run a report you can use the DomainAccessGuard.Sessions property as a start. You could use that to write a report with Sitecore Powershell Extensions pretty simply.
Log files usually contain audit information about login / logout. E.g.:
6140 13:57:33 INFO AUDIT (sitecore\djanjicek): Login
...
7512 14:02:57 INFO AUDIT (sitecore\djanjicek): Logout
With Sitecore Log Analyzer you should be able to filter your log files on the audit trails.
https://marketplace.sitecore.net/Modules/S/Sitecore_Log_Analyzer.aspx
If you need a web based solution then you could write an admin page that reads all log files and outputs the required lines in a timely fashion.
Also, you can try this:
var x = Membership.Providers["sql"].GetNumberOfUsersOnline();
where "sql" is you membership provider name defined in configuration.
Related
I have created a simple (display only) SPFx webpart that makes calls into a list on the same site as it is used. Standard users have read access over this list, site owners have Full Control. When I add the part to a page, even site owners cannot see it. Site Members (& Owners) are able to see the page (published or not), but the content which should be displayed by the webpart is missing. Note that the basic html is visible, but the data which should be retrieved is not. If I elevate a site owner to a site admin permission level, the webpart then works as intended and data is retrieved correctly and displayed. Note also that other webparts on other pages served from the same library work correctly for all groups.
Does anyone have any suggestions to explain this behaviour?
I have tried: Rebuilding and publishing webparts, new test pages created by the same and other user accounts both published and unpublished. I've carefully changed permissions on the "Site pages" library, the "ClientSideAssets" library and the site scoped app library itself.
I've answered my own question here. The error was caused by a REST query into the SPO list that contained a taxonomy (managed metadata) field. Expanding this field appeared to require the highest permission levels, thus all non admin users were unable to retrieve the data.
I later found an excellent article detailing the subject here.
I was able to trace this by serving through gulp into the online workbench, copying that URL into an incognito window for a different user account, and utilising the (Chrome) debugging tools. This tidy solution might potentially be of use to someone.
In Liferay 7 Enterprise Edition,
I want to log user info like user_name in external log files automatically in each request to track user activities, how to do that?
without using auditing plugin
when I tried to log post request for example (login), it doesn't contain any info about user ?!
This kind of thing is much harder than you might think...
Getting access to the current user is really easy. As Victor pointed out, you can use the ThemeDisplay object to get current user. If you don't have the request around, you can use the PrincipalThreadLocal to find the current user id.
That gives you the who, but certainly not the "what is user doing" aspects. Since the portal aggregates the HTML fragments of many portlets, from a servlet filter perspective it would be hard to gleam which one of the available portlets on an incoming URL is actually being interacted with. You could try a portlet filter to narrow the field, but this will just tell you what portlet is being accessed but not what they are doing with it.
Although you rejected the built in audit functionality available in DXP, it really is the answer for tracking who did what in the portal because it has the necessary touch points to get those two pieces and put them together.
Now if you rejected the built in audit functionality because you want a file and not a database entry, that is easy to solve. Go to the System Settings control panel and find the Logging Audit Message Processor and enable it. It will write the audit events out to a file in CSV format, but you should have the source for modules/apps/foundation/portal-security-audit/portal-security-audit-router/src/main/java/com/liferay/portal/security/audit/router/internal/LoggingAuditMessageProcessor.java so you can use this as a basis to write your own format.
Look at this code:
https://github.com/amusarra/liferay-portal-security-audit
in particular the portal-security-audit-capture-events module that catch the login events.
This seems a job for a filter, the user information is normally extracted from the themeDysplay, like in:
ThemeDisplay themeDisplay = ( ThemeDisplay ) request.getAttribute( THEME_DISPLAY );
long userId = themeDisplay.getRealUserId();
If you want to track specific portlets, an OSGi portlet filter would do the job.
I have 10 qlikview app in AccessPoint and for specific user i want to show only 7 app.
I don't wont to use Section Access.
I use NTFS authorization
And on folder Production (where save qvw app for browser) in Properties Security i remove specific user but he still see app...
How can I handle this?
By your description it sounds like you are using publisher.
If you want to display certain QVW's to certain users, then you need to setup the distribution to "Named Users", that way you can only add users to the relevant apps and the people that are not named will not see the QVW on the accesspoint.
Also make sure on the actual QVW (right click on it, properties, security) that only the relevant people have security rights on the file.
I have a DNN (5) internal website that I need track URL's. I am unable to use any external analytics (Google or otherwise), so I have to rely on the internal installation as-is. I have also tried a tracking tool, but it does not give me what I need, which is really just raw page and user info. I have also tried to look at the [UrlLog], [Urls] and [UrlTracking] tables, but even though I am navigating pages, nothing is listed. The [eventlog] is logging events, so I know I am on the right site. I don't necessarily want to create new tables and log event separately if DNN does log it anyway. I would prefer to just be able to query it directly via SQL (or via the reports module).
Any guidance will be appreciated.
You can enable the SITE LOG in host settings, that will start to track a lot of information in DNN, by default it is set to 0 days, which won't store any history.
For existing portals, you will need to go into the individual portals settings and update the SITE log to also reflect the correct number of days. HOST is only used for new sites created.
I'm setting up a wiki at the moment and I want it to be completely private and only be accessible for a specific user group.
My first step was:
$wgGroupPermissions['*']['read'] = false;
that way no one (but admins I guess) should be able to read any content of the Wiki.
After that I created some groups to allow read only, read edit and creating allowance etc.
Sadly I tried to register a new test account and I could still read the main wiki page even though I changed the permission that no one should be able to read it except the user groups I created.
Do I miss something?
You need to add $wgGroupPermissions['user']['read'] = false; as * still allows visitors in the users group to read.
That method specifically allows Users that have created accounts to view the wiki. See this manual page: https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_viewing_of_all_pages, it's the second Warning. So you may want to also restrict account creation.