Hi I need to make a dynamic menu in my struts2 application, so there should be two different menus for members of website and guests, currently I am using Struts2 and tile to have a basic menu but I do not know how to change it for members when they are logged in.
Well you have few options here
Create two menu set and when user got logged in to the system set his/her role and based on the role can show the menu items.
other solution, which is more flexible elegant and more powerful is to use spring security.Spring security comes with role system and some set of tags based on which you can show and hide option based on the logged in user and role assigned to the user.
I will go with the second one as its more flexible and easy to enhance in future.
Related
Unfortunately I have a problem with an Forum Based on Domino FP9 Server. Several pages are created with the framework/language xpages. I have created a group and also a category. But the user is unable to get access the content.
My question is: How I can implement the right to an Group inside HCL Admin or Designer to read content on an Page?
Kind Regards
Okan
Access is granted via the Access Control List of the application. In HCL Notes Administrator, find the application on the Files Tab. Right-click and choose Access Control > Manage. IMPORTANT - DO NOT choose Manage Directory ACL in error.
In the dialog that opens up, you should be able to add groups/individuals with appropriate levels of access.
Not exactly sure what the problem is.... i.e. what it has to do with HCL Admin or Designer to do?
However, security in an XPage is exactly the same as with everything else Notes/Domino - so you can use that knowledge to control access rights.
A group in reality works like a single person in terms of access. So you can use it in the ACL of a database and/or in Readers/Authors fields (to control access to specific documents).
If you want to control functions or layout inside your application then I would suggest using Roles as these give an extra abstraction layer and are way easier to use in e.g. hide-when formulas inside your code. And then you just assign the role to a group or person in the ACL of the database.
Remember to set the right type of the entry in the ACL (e.g. Persons for a group that contain persons) - otherwise you can have issues where the server will not grant the expected access ;-)
Can you please help me on how will I able to filter the items of my list in Sharepoint depending on the user logged. The items that need to be shown will also depend to the team where the user belongs.
Thanks in advance!
So the image below shown is my list.
For example, User 1 and User 2 both have Full Control permission on my list. But User 1 should only see entries for DETE team. And User 2 should only see entries for Service Control Team.
Showing which items to be shown based on the current user can be done using out of the box SharePoint permission features.
The simplest and short answer is to set unique permissions on each item in your list to specific users or groups by breaking permission inheritance for the SharePoint list. Once the inheritance is broken, you can then specify your unique custom permissions on each item in your list. Then SharePoint will only show what is available for the user to see. If you are not familiar with security inheritance in SharePoint, then I suggest reading up on this topic as this is a foundation of SharePoint security.
To do this, use the "Shared With" -> "Advanced" options from the ellipsis menu on that item, then you can break permission inheritance on that item. (If you don't see the tool ribbon, then change the "List Experience" setting to classic via list settings -> advance settings -> list experience)
Then break the permission inheritance on the item:
Then you can grant permission to specific users or groups:
This can work okay for a small list but is a management nightmare for a large list.
One alternative is to use "Folders" and set the appropriate permissions on there instead. Then you can add/remove items from the folder for easier management to control which users can see what. There are pros and cons with this approach but this method has worked for me. What is nice is that you can display the items with or without folders using the Folder display options when creating a custom view.
Another solution is to create a custom workflow that will apply the proper item security permissions for you when an item is created in the list. This is good to automatically set the permissions for you without doing any work but does add maintenance duties if permissions needs changing such as new users, remove users or modifying users.
Setting up the proper security groups and users should give you the flexibility needed for your security requirements. It is always good practice to use groups when possible.
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.
My company is running its own server with WSS 3.0, and I am using Sharepoint Designer 2007 to make changes. I am new to the world of sharepoint (but experienced with webservers and web programming), but basically what I am trying to accomplish is this:
We are trying to automate forms that all employees must fill out (for example, our Employment Application). Since all employees have access to our sharepoint intranet, we will put it on there. It must do the following:
Display a form where users can enter their data. Once submitted, the data is stored in a database (sharepoint uses Lists for this I believe).
A user can go back to the form to edit things if need be (and their old data will be automatically loaded).
User’s should only be able to access their own form and not see everyone else’s. Only admin’s should be able to see everyone’s stuff.
What is the best way to go about accomplishing this? Can I create a standard list and modify it to suit my needs? Do I need to code some ASP forms to make this work? Is there an inexpensive web part that can do this sorta stuff?
I don’t think using Infopath is an option for me since I have wss 3.0 I would need the end user to have infopath as well, and many won’t have it, so that rules that out.
I think you want to adjust the Item Level Permissions setting of the list. (List Settings->Advanced Settings)
The form in SharePoint States:
"Item-level Permissions
Specify which items users can read and edit.
Note: Users with the Manage Lists permission can read and edit all items. Learn about managing permission settings."
There are settings for Read access and Create and Edit access:
Read access: Specify which items users are allowed to read
-Read all items
-Read items that were created by the user
Create and Edit access: Specify which items users are allowed to create and edit
-Create and edit all items
-Create items and edit items that were created by the user
-None
This sounds like you simply need a custom list, possibly with custom forms (edited with SharePoint Designer) in case the default forms aren't adequate.
How can I disallow adding item or document to a list or document library? Due to some other feature scenario I cannot break role inheritance and have custom permission set for the list. Today, we restrict the addition using event handler (Item adding) – but this leads to poor UX.
Is there a way to have Role inheritance for a list and still have a base permission mask? Something like, allow everything that parent web offers but not X,Y,Z. Breaking role inheritance in the traditional way introduces the problem of explicit User and role management. Having a SPGoup hold an another SPGoup could help here, but that too is not possible. Let me know your suggestions.
I think you are asking to allow a user to have add permissions to the list but not actually be allowed to add to the list. Event receiver is going to be the best way. The only other solution I can think of is to use a custom item form that will do the check.
You can solve your problem by creating a webpart with the below functionality.
Identify the logged user is in admin group. If he is not in that group ganarte a javascript alert that "you have no permission for add new item" and redirect to (location.href="") allitems.aspx page.
And place this webpart in Newform.aspx page.
(add &toolpaneview=2&sharedview=true in in Newform.aspx url for editing page)
Hope this helps. Let me know if you need more help.
Create an IHTTPModule and subclass the context AuthenticateRequest event.
In the AuthenticateRequest routine you can inspect what type of action is happening and then redirect the user to the SharePoint "Access Denied" page. This is exactly how SharePoint does this functionality so the UX experiance would be the same.
If you want my opinion I would go with the way SharePoint handles permissions out of the box and break role inheritiance. Sure it will add new complexities to your life. But, I think you can better manage these complexities with the SharePoint Admin Toolkit and some custom built utilities for managing permissions. I think that is a better solution than what you are trying to do.
Am I missing something here when I suggest: Just hide the toolbar (or specific button) in the view page? That's an painless CSS hook done in the view page or SharePoint Designer
If you are using a custom List Template, you could create a custom View Toolbar Template. However, you probably will not want to use this on an OOTB List Template and it doesn't look like this will work on an existing list.
Even if you implement this, I would still leave the Event Receiver in place in order to prevent URL spoofing.