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.
Related
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.
Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.
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.
I want to allow anonymous users view access to a private folder & it's contents, only after they have submitted a valid email address through a form. I thought of emailing them a link to the folder, perhaps with a token that gives them access or logs them in, but I'm not quite sure how to do that.
I'm currently looking at collective.powertoken.core & collective.powertoken.view, but it seems that these products cover access to a single content item, rather than a whole folder.
I'm wondering if it's better just to add low priviledged users to the system & log them in without passwords.
Thanks
as suggested by #keul, you can use redomino.tokenrole.
If you want to integrate the tokenrole feature with a PloneFormGen you might consider to have a look at redomino.tokenroleform (https://pypi.python.org/pypi/redomino.tokenroleform): It is a custom plone form gen adapter that let you share a private object via token.
I don't know if redomino.tokenroleform fits your use case.
But you can browse the code in order to understand how to add a tokenrole programmatically.
Both products are for very low level usage.
Try redomino.tokenrole: https://pypi.python.org/pypi/redomino.tokenrole
A quick api uri design question. We have resources that belong to our clients. These resources can be edited / viewed / deleted by the client who entered them into our system. The resources can be searched by all clients but access is only granted if certain criteria is met (client has level 3 access etc).
Choice 1: include the client who owns the resource in the uri.
client/:clientname/widgets
client/:clientname/widgets/:id
Choice 2: ditch the whole "client/:clientname" since this part of the uri has to be verified and checked against the credentials of the user accessing the information.
/widgets
/widgets:id
We have other resources other than widgets that also belong to clients.
Which way is the more preferred way and why? Cheers.
The only advantage that Choice 1 gives it that it allows you to effectively namespace widgets/whatever by the user that uploaded them. Similar to Github, how different users can have projects with the same name. If Github were to exclude the username, no two users could have a project with the same name. If the widgets are all unique, I would go with option two and you will have a 1:1 mapping from a widget the the user that created it, thus supplying it is just extra work for whoever is calling it.
If you can have the same widget name for different users, use an approach which includes the username. You may not need to actually use the 'client' word in your url though; using a path like '/:clientname/widget/:widgetid' instead.
Note that this is kind of an opinion based question, so you may get different answers. You'll have to weigh the information provided and in the end make your own decision.