You can use Sharepoint Client Object Model for this. Here is how to do it on the current web:
context = new SP.ClientContext.get_current();
web = context.get_web();
this._currentUser = web.get_currentUser();
I see two differences one difference:
The function SPContext.Current.Site.OpenWeb() creates a new instance of the SPWeb object, and you are responsible to dispose it.
However, SPContext.Current.Web gives you access to the current instance of SPWeb, and you must not dispose it.
The function SPContext.Current.Site.OpenWeb() (without sending
parameters) opens ...
It depends on what you need to do.
RunWithElevated only runs as the Application Pool Identity, so you might not have access to other web applications, only other site collections in the current web application, but you can be guaranteed that you will be running as a user that exists (the AppPool identity).
With UserToken, you need to be sure that the user ...
Take a look on msdn
foreach (SPUser user in group.Users)
But be aware that you change this group for the whole site collection, if you have other site collections those won't be impacted by the modification of this group.
Hope this will help someone because I faced the same issue. The claims based token is refreshed every 10 hours and hence if you make any changes to Active directory group memberships it won't reflect immediately in the token. you need to run the following powershell command to adjust the token life time to a smaller value.
$sts = Get-...
I'm assuming in the list's Advanced Settings page you set "Specify which items users can read" to "Only their own".
You need at least the "Manage Lists" permission which is present in the following roles by default:
So... a user would need at least the "Manage Hierarchy" role set in the list's permissions.
See also, ...
There are few security risks linked to Google Analytics. Your SharePoint site will not be hacked because you use Google Analytics. You cannot be 100% sure, but the only "safe" way is running log processing software on-premise or use built-in Web Analytics.
However, I believe the largest risk are concerned with the legal aspect of possibly exposing internal ...
I didn't want to take credit for answering my own question so i did it as an edit but the following resolved MY issue:
UPDATE: The issue had to do with the fact that the Security Token Service was not functioning properly. I'm still not sure that i'm clear on how to correctly change managed service accounts, passwords, etc. But I DID get it working. I guess ...
You could also use the Microsoft Threat Management Gateway 2010 (TMG 2010) to publish your SharePoint intranet in a secure way. It could for instance be published on a Web address like https://intranet.yourcompany.com
Now, my suggestion does of course require that you are using the TMG as a firewall between the internet and your internal network. But I can ...
This will give you the Farm Administrators:
$ca = [Microsoft.SharePoint.Administration.SPWebService]::AdministrationService.WebApplications | Select -First 1
$root = $ca.Sites["/"].RootWeb
$grp = $root.SiteGroups["Farm Administrators"]
Get-SPManagedAccount will give you managed accounts
There should only be the farm admin common in these ...
1) Create the following regular text file
<!-- JS code goes here -->
and upload it into Site Assets library
2) Add a reference to a file via via Content Link web part property
Elevated privileges is not enough to write to the configuration
database. With elevated privileges you will use the the web
application app pool’s identitty, which has only read permission to
the config db by default. Of course admin user (which runs the central
admin should have read and write permissions).
See more at: http://joelblogs.co.uk/2010/...
Just like to clear this answer!
I've read your question and the answer has to do with the security context that has been put in place for a reason.
When using the SPContext.Current.Web or any context appart from .OpenWeb() it is already using the current users security context(read, write,full permissions). Open web is creating a new SPWeb object ...
The right way to grant access is to use the SPWebApplication.GrantAccessToProcessIdentity method. It sets up the database permissions for you, but remember to run it again if you add content databases.
You can do this with the following PowerShell:
$webApp = Get-SPWebApplication TEAM_SITE_URL
$webApp.GrantAccessToProcessIdentity("domain\username of MY SITE ...
A crawl is never started by anything changing in SharePoint, neither content nor security changes.
A crawl is either started manually or according to the specified schedule.
If you're using search, then you probably have a crawl schedule set up which does incremental (and sometimes full) crawls. The full crawls with crawl everything and the incremental ...
You just need a small change to your PowerShell script.
$web = Get-SPWeb http://webUrl
$groupOwner = $web.SiteGroups["GroupA"] #this group will own "GroupB"
$groupTarget = $web.SiteGroups["GroupB"]
$groupTarget.Owner = $groupOwner
For all groups in a web:
$web = Get-SPWeb http://webUrl
$groupName = "SharePoint Group Name" #this will ...
Sorry, but there is no way to run at elevated privileges from the client-side, and if there was a way, it would be roughly 0% secure.
Depending on what you're trying to achieve, there are some ways that you might be able to work around it.
For instance, if you can do it from a workflow, SharePoint 2010
workflows can do an impersonation step which runs as ...
There is no such thing as read vs. write access when securing a URL to a web service - You can reference the Web Service URL or you can't. The services themselves are implemented to enforce security just as if you were logged into the site through the browser.
Without access to _vti_bin you are pretty much out of luck for any of the SharePoint Web Service ...
This mix of AD groups and SharePoint groups is always a problem. You sort of get 2/3 of what you want by using AD groups and 2/3 by using SharePoint groups. It really comes down to what is more important to you.
I have a couple of blog posts on this dilemma:
Make the site available over SSL. No point in havign the access to your site in order when anyone can just intercept all the data retrieved by users because the connection to the site they use is not secure.
If you don't want to use SSL to access the site from inside your network, you can use SSL offloading (using TMG or a hardware loadbalancer). This ...
When you break permission inheritance at library level, all items in the library will have same permissions as your document library. At this point, you are NOT using item level security. When you check the permission of document, it would be "inheriting parent (which in your case is Document Library containing the document)". This is a very valid scenario ...
You can set it like this:
public static void AssignPermissionsToItem(SPWeb web, SPSecurableObject secObj, SPPrincipal obj, SPRoleType roleType)
SPRoleAssignment roleAssignment = new SPRoleAssignment(obj);
SPRoleDefinition roleDefinition = web....
UpdateCurrentweb.AllowUnsafeUpdates = true;
up before the call to EnsureUser. Maybe even further out depending on what RemoveFromGroup does.
There is no need to set it to false unless it's something like SPContext.Current.Web which is passed to other components
To remove site permissions for a user, you will have to remove the user from the group to which the user has been given permission to. Sample code would look like this -
$site = new-object Microsoft.SharePoint.SPSite("Site URL")
$web = $site.OpenWeb()
$oSiteGroup = $web.SiteGroups["Group Name"];
$oUsers = $oSiteGroup.Users
foreach ($oUser in $oUsers)
Well, SPSecurity.RunWithElevatedPrivileges should do the trick.
Make sure, you create a new SPSite/SPWeb within the elevated code block:
var siteId = SPContext.Current.Site.ID;
using (SPSite site = new SPSite(siteId))
//do things on the new site object