We are having a requirement according to which the access on the Web contents is to be given on the basis of categories.
Example: (i.e): if a role Report is being given to a user, then the user should be able to view only those web contents which are associated with the Report category.
How can this be achieved with liferay 6.2?
The UI will have nothing for you, as this is not the typical way that Liferay handles permissions. There are several options that you can choose from:
First of all you should check why this requirement exists: Quite often I'm seeing permissions being used where "relevance" is actually the way to go: Check if users absolutely must not see content from other categories, or if it would just be irrelevant for them. Don't use permissions to solve "relevance" problems.
My favored solution would be that you determine this is the case. If it isn't here are some other options that you have:
Liferay's permissions work best (and best maintainable) if you separate content with different permissions into different sites. This way you can use the easiest bulk permissions. You can create all the different content in different sites and still show them on other sites - e.g. through AssetPublisher or custom portlets.
You can also create a Hook that automatically sets the required permissions whenever an article is saved. Liferay's API is available and can be overridden with the required operation. In fact, you won't override, but rather add to the standard behaviour.
Related
I have a couple different Sharepoint pages (Sharepoint Word docs) all with roughly the same purpose and information, but for management reasons, some of it needs to be restricted from a certain set of users. We keep having to update each page in several different places any time a single change or update is made.
It'd be easier to be able to mark certain tables on a single page with specific permissions. Is that something Sharepoint can even do, though?
Providing you have an enterprise license for on-premise the best way to achieve this is by using targeted audience feature on the webparts.
You could check SecurityTrimmedControl, you could hide the content based on user permission.
https://rijsat.wordpress.com/2016/10/27/security-trimmed-control-in-sharepoint-2013/
I have the following scenario:
My Add-In allows to write posts. Any user may "Like" that post. That likes are being saved into a list.
Of course the Add-In needs permission to write that entry into a list. But as (IMHO) I cannot use any elevated privileges inside a SharePoint - hosted Add-In, the user needs to have that permission, right?
So: How can I protect my lists that the user don't just go into the list and modifies the value himself and increases the "likes" for example?
(remark: This is no real-world scenario. I know there are better ways to use a social network-feature. Just wanted to break down my much more complex app)
SharePoint-hosted add-in cannot use App only policy as provider-hosted add-in can to use add-in context with more permissions then user has. SharePoint-hosted add-in is running completely in the context of current user.
I see 3 possible solutions:
Redesigning the add-in to be provider-hosted)
Implement custom web service and calling this web service from your add-in. That web service can store sensitive information in either custom database or list in app web with customized permissions. But remember that SP admin can modify these permissions.
Store semi-sensitive information into extended properties of item. There's no UI allowing user to manipulate with it but this is not as secure as permission. Advantage of this is that this information is directly connected to the "affected" item and you don't need to afraid of loosing connection between item and like storage. Disadvantage is that extended properties can contain only limited amount of data and user must have permission to update item. You can also use this approach combined with your list.
I would make each user's 'like' click create a new item in a list that has the Item-level Permissions set to:
Create items and edit items that were created by the user
That way even if they did somehow get into the back end and start monkeying around with the list they would only be able to change the items they created.
You'd just need to manage how the list grows over time depending on the scale of the app.
You are correct. The user would require the something like "Contribute" permissions to accomplish what you are talking about. Personally, here is what I would do...
1) Ensure the list I want to protect has an obscure name. Remember, the UI is not the same as in the host web (i.e. Site Contents). The user never has to know in what list such data is stored. Taking it a step further, ties between lists could be made by something like a GUID instead of something obvious like "Title", making it more difficult to determine exactly how data relates.
https://sharepoint.stackexchange.com/questions/96360/hide-list-from-browser-site-lists-lisname
2) Delete all views in your sensitive lists. This would prevent navigation in the browser. These lists would be modified through REST or CSOM, so you do not need them.
3)I haven't tested this possible solution, but it may work. You should be able to configure the edit.aspx (or create your own custom one) so that even if the user somehow made it past Steps 1 and 2, there was no available fields to edit anyways...
These methods do not manipulate the permissions to the list in any way and in the end, all of this is permissions through obscurity.
Is there a way in WSS 3.0, Windows Server 2003 to restrict in a document library the list of Views a given user or group is allowed to select/use?
We have defined document libraries and Views that show only the documents a user or group is allowed to see. The problem we have is that any user could select a View that is meant for a different group.
And upgrading to MOSS Enterprise is not an option for now.
In your question you say you have views that "show only the documents a user or group is allowed to see." And the problem is other users can see these views, and therefore see documents they should not. It sounds like the bigger issue you have is using views for security.
There are any number of ways a user can see a document that isn't presented to them in a view. If your intention is to prevent users from seeing certain documents your best options are to use separate document libraries and set permissions accordingly (which inherently gets around your view problem) or put your documents in folders and set item level security on the folders.
As far as your question, I think the answer is no, you cannot prevent a user with permission to a document library from seeing its public views. If a user has permission to a library they have permission to the views as well.
If you're really not worried about security you could always create a custom page to view documents through, and on that page limit the views that are presented in the UI. How you'd approach that depends on your skill set and what tools you have. These types of solutions are messy though, since it relies on your users going through your custom interface, and there are many ways SharePoint will take your users to the OOB pages instead.
I have a specific requirement where-in I want only the uploader of the document and a specific team to be able to view it in list / library. 1) is it possible? 2) If yes, how...?
Ok. So I was able to resolve my issue with the steps mentioned below. Soon will be documenting it in form of a blog and share it:
Created the document library and modified the default view to only show documents that were created by/modified by [Me].
Added a new web page to the library and gave exclusive rights to access that to a certain set of users.
Restricted all users from creating a view with the help of creating special permission level where user only had access to upload or delete a document but not creating/updating/deleting lists/views. Also disabled private view creation.
Hope this may be helpful to others too who are looking for restricted views / disabling view creation.
You need to set item level permission through event handler:
http://www.chakkaradeep.com/post/SharePoint-ndash3b-Setting-Item-level-permission.aspx
http://msdnvietnam.net/blogs/quang/archive/2009/07/02/sharepoint-eventhandler-set-item-level-permission.aspx
#Ashish, in SharePoint 2007 GUI you cannot make a query that will show documents that belongs to a specific group, however CAML specification supports it (Membership tag), it wasn't documented until SP2010, but it works on SP2007 (i'm using it)
However this involves custom coding and this doesn't assign permissions automatically, it just enables you to filter documents by groups.
For a solution without custom coding you could consider making a seperate folder/list for every person/group and set permissions to folder/list accordingly. This will also help performance - it's better to have permissions set on high-level container than having fine grained permissions (i'm just assuming that, because i read everywhere that mass fine-grained permissions are bad for performance)
You may use current user filter web part to filter the document by whom logged in into the sharepoint site by passing the value Dispaly Name
I am developing a sharepoint 2010 project.
I want to restrict users view on lists based on their identity. (e.g. the branch of organization they work in, but in fact the ristrictions can be more complicated).
What solutions do you recommend?
With out of the box features this is not possible. You can go to great lengths to remove the list's view selectors and other navigational elements that let people cruise around a the schema and metadata for a list but it is not a security mechanism.
If a user has read permissions to an item, they'll have read access to all the fields of that item.
There is an outside chance that it you disabled all RPC mechanisms, SOAP, RESTful web services, Client Object Model and the office clients that you might be able to claim this as a security mechanism. If you don't there will always be a way around your "security" scheme.
This feature can't be implemented by SharePoint by now and I think neither for the next version
You can use a third part tool to achieve it, such as BoostSolutions' Column/View Permission or LightningTools' DeliverPoint
BTW, I work for BoostSolutions and I mentioned our own product because it works for your issue. Hope it helps :)
create sharepoint groups based upon your requirement or diffrent type of user base and accordingly give them rights may be item level or on complete list
and while doing these things just go through the following posts
http://blogs.gartner.com/neil_macdonald/2009/02/25/sharepoint-security-best-practices/
http://weblogs.asp.net/erobillard/archive/2008/09/11/sharepoint-security-hard-limits-and-recommended-practices.aspx
Not 100% sure on SharePoint 2010, but definitley for SharePoint 2007, there is not a way to do this, especially if the views are corresponding to security requirements on the columns users are able to see.
One way to work around this is have the list be not accessible by users, and then have code logic allow for access to the data creating the different "views" on the data in something like a Web Part. The downsides to this is search becomes an issue (since the data is hidden) and having multiple "views" of the data (if necessary) is also another item to work through.
I know its a very old question but posting it as it might help someone.
There is an work around to do it as described here
I find it easier, if possible, to create the view and lock it with the filters on the list settings page.
For example, I have a list of employees that includes their employee IDs. I use that list on other pages to gather data in other webparts. So I filter the employee list to [ME]. So the data is available to the page needing it to filter others and they cannot see anything else.
Now, what about the person who needs to manage that page? I create a view, call it HR. That view can see everything. Then I export that webpart with that list view on it through the designer. I then delete the HR view from the employee list.
This leaves no way for anyone to switch views and see everything again. I create a webpart page for the person who manages it, and I upload that webpart and set the view of the webpart to HR. In the end, I have a page that I lock down instead of trying to lock down views or list permissions separately.
Would you be able to have two lists that are joined. One that all users have access to and another that only certain people have access to, and then join them? Then maybe the people that don't have access to the other table it doesn't pull the information? Not sure, but I'll try that out later today.