I need to set up IP filtering in a SharePoint document library based on a group that a user is a member of. More specifically, we have groups set up for each of our customers. Each group should have an allowed IP address attached to it. When a user accesses this document library, we then need to ensure that the user is coming from the IP address attached to their customer group. The IP filtering would only apply to a single document library, not the entire site.
My only idea so far is to create a webpart that checks the user's IP address and redirects if it isn't correct. Then I could put that webpart at the top of a webpart page, and display the document library webpart below that. That's a little hokey, so I was hoping someone had a better idea.
The problem with your proposed solution of a webpart on the AllItems.aspx page is that there multiple ways to get to a document and this would not prevent someone with a direct URL from accessing the document.
You want to take advantage of SharePoint's permission structure. If the documents can be grouped by security, then you could create one library per customer (or one folder within a single library) and set the permissions based on your SharePoint groups for the library/folder. That may not work for you if you need to have one document that is available to multiple groups.
Another option is to set the library security to be restricted to only one system account. Then you could write a webpart (or application page) that checked the user's IP address and using RunWithElevatedPermissions you could get the contents of the libary that are applicable to that user. That would solve the issue of a direct link because they would have to go through your page to access the documents.
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.
I have a requirement to fetch all active directory users data to be added in sharepoint list and show on different pages.
How we can achieve this?
see below to get C# code to do that. Depending upon the sharepoint api (Server object model/CSOM/JSOM) you are using, you would have to take the results from this code to your pages.
How can I get a list of users from active directory?
I'm creating an app that will be configurable by the end-user to access SharePoint lists, on various different SharePoint sites, that are entered by the user.
All of the examples for reading SharePoint lists I've come across online are of the form:
Open or create a Visual Studio
project.
In Solution Explorer,
right-click the References node, and
then click Add Service Reference.
In the Address box, type the URL to
the target site and append
/_vti_bin/ListData.svc. For example,
the address for the site
intranet.wingtip.com would be
http://intranet.wingtip.com/_vti_bin/ListData.svc.
Change the default name in the
Namespace box from ServiceReference1
to something more appropriate, such
as WingtipSite.
etc, etc, etc
This method creates proxy classes within your project based on the specified server reference. However, in my case, the server/site is not known at design time, only runtime by reading the sites/lists specified by the user. How would one go about doing that (reading the list via http://intranet.wingtip.com/_vti_bin/ListData.svc, but at runtime only)?
Note: I am making this call from a different machine than the one running Sharepoint.
There are a couple answers.
If the lists schemas will be consistent across all the sites you are querying, you can still use the generated proxy. When you create the DataContext, you just need to pass in the URI to the ListData.svc for the site chosen by the user.
If not, then you can use an ASP.NET WebRequest with an appropriately formatted URI and parse out the ATOM or JSON response that comes back.
For more information on using the REST APIs, check out this talk from the 2009 SharePoint Conference
http://msdn.microsoft.com/en-us/sharepoint/ff462048
You can set the URL in your proxy class at runtime with the Url property.
SharePoint does not provide a proxy class for their web services. Therefore it's not possible to set the url at runtime. WHat I have had to do is add 2 service references and then paramaterize which one I will access. I use a config setting to determine which one to access. If the site name changes or list changes, then I need to remove the references, re-add them, recompile and redeploy. There is no way to change the SharePoint site/list at runtime. Have been searching for 3 days for an answer. Microsoft does not know how to accomplish this.
We have a sharepoint environment with many sites (and sometimes many site collections). Each site (or site collection) has the same default page with some custom webparts that use sitecolumn values (for example a projectcode or clientcode) to show information from external systems. (for each project we have to create a separate site (or site collection) because of other reasons)
What is the best approach to minimize duplication? The dynamic parts of the page are stored in site columns. When we add a new webpart, ideally the default page every site/page should show the new webpart without spreading the update to the individual pages
Thanks
One approach you may want to take is to use the web part as a wrapper for a user control. The user control does the heavy lifting on the site. Once the web part is included on your pages, the user control should be able to tell which site it is being executed on and pull the necessary dynamic data from your site columns.
When you need to make updates, you update the user control and then redeploy the solution package to the farm. Each site will pick up the change as soon as the solution is deployed.
Here is a little information about this approach:
http://msdn.microsoft.com/en-us/library/ff649867.aspx.
The above article relates to WSS 3.0, but that should give you a starting point.
An approach you may want to look at for SharePoint 2010 is a visual web part. More info can be found here: http://msdn.microsoft.com/en-us/library/ff597539.aspx.
I am working on SharePoint 2010 instance. I want to be able to view list content in the SharePoint site that this list doesn't belong to. My site does not even share the same site collection as the one containing the list. Is this possible without the custom SharePoint solution coding? Thanks.
Here is a workaround:
http://sp2010.pathtosharepoint.com/SharePoint-User-Toolkit/Pages/Cross-Site-List-Snapshot.aspx
This will work across site collections, as long as the source and target pages are in the same domain. It'll work fine if your only purpose is to display the content, not use the context menus.
Other solutions like Data View Web Part or Content Query Web Part won't work across site collections.