I have written a fairly straight-forward JavaScript for SharePoint Online that I am deploying as a user custom action into the root site collection using CSOM.
The following code is the block I am using for provisioning the script to the site collection:
public static void ProvisionScriptLinkCustomAction(ClientContext ctx, string name, string url)
{
Site site = ctx.Site;
ctx.Load(site.UserCustomActions);
ctx.ExecuteQuery();
foreach (UserCustomAction action in site.UserCustomActions)
{
if (action.Name == name)
{
action.DeleteObject();
break;
}
}
ctx.ExecuteQuery();
UserCustomAction customAction = site.UserCustomActions.Add();
customAction.Location = "ScriptLink";
customAction.Name = name;
customAction.ScriptSrc = url + "?" + Guid.NewGuid().ToString();
customAction.Update();
ctx.ExecuteQuery();
}
I am logged in as the tenant administrator when deploying and initially testing the custom action. Everything works as expected until I log in as a user that is not the tenant admin. When logged in as any other user that is only a site collection administrator or lower, the custom action does not fire and all of my efforts are for naught.
This feels like a configuration or permissions issue to me but I am at a loss to begin to know where to look to rectify this issue.
Any helpful thoughts would be greatly appreciated!
Turns out I had console.log calls in my JavaScript. Some versions of IE apparently do not know how to log to the console when in browser mode without debug tools which presumably throws an uncaught and unlogged exception. Removing the console.log statements made the issue go away.
Related
I have this in a webpart inserted into a page from Sharepoint Admin Site (http://sharepointserver:port) and I want to read some info from mysite:
SPUserToken objSPUserToken = SPContext.Current.Site.SystemAccount.UserToken;
//SPUserToken objSPUserToken = SPContext.Current.Web.CurrentUser.UserToken;
using (SPSite mainSite = new SPSite("http://sharepointserver/sites/mysite", objSPUserToken))
{
SPWeb mainWebSite = mainSite.OpenWeb();
SPListItemCollection listItemsP = mainWebSite.Lists["Pages"].Items;
}
When I run it from Visual Studio, asks for user/password and executes normally, but when I publish the wsp and run it from browser, I have the message:
Sorry, this site hasn't been shared with you
I've tried with the CurrentUser (commented line) and it gaves me the same message even from Visual Studio.
I'm sure that the user has rights into mysite, Do you have any idea of what´s happening?
Thanks!
Modify the code as below.
SPSecurity.RunWithElevatedPrivileges(delegate()
{
//New SPSite object.
using (SPSite mainSite = new SPSite("http://sharepointserver/sites/mysite"))
{
using (SPWeb mainWebSite = mainSite.OpenWeb())
{
SPListItemCollection listItemsP = mainWebSite.Lists["Pages"].Items;
}
}
});
Reference: SPSecurity.RunWithElevatedPrivileges method
I finally got it, the reason behind the message "Sorry, this site hasn't been shared with you" is because sharepoint log into the site not as the current user but the pool's account, so the message indicates that the site has not been shared for the sp_applicationpool or sp_farm accounts. I solved adding thats accounts into mysite.
Thanks for your help!
I have a SharePoint 2010 MySites set up on its own web application. There is the standard site collection at the base level, http://site:80/.
The personal sites for each user is at the managed URL /personal/.
I have a working event handler which add items to the Newsfeed when a user adds something to a picture library.
THE PROBLEM:
The problem is, this only works if they add to a picture library at the base site collection, http://site:80/, and does NOT work if they add to http://site:80/personal/last first/.
Does anyone know why? The event handler feature is site scoped and my understanding is that it should work on all subsites.
The problem is that personal sites are not subsites of My Site host. In fact each user's personal site is a site collection on its own. So basically you need to register your event receiver not only for My SIte host, but also for each user's personal site.
Ok. Because you can only 'staple' features to site definitions which will be provisioned in the future, you need a way to activate new features on existing sites.
So, the fix I discovered and used follows:
The default page for the newsfeed is http://site:80/default.aspx. If you create an event receiver and scope it for 'site' and deploy it globally or to that web application, then it will work on the base site collection. Each personal site is a site collection and has the feature but it needs to be activated on each personal site collection.
So, in the default.aspx page, you place the following which will activate the feature if it has not yet been activated.
<script runat="server" type="text/c#">
protected override void OnLoad(EventArgs e) {
base.OnLoad(e);
String sAccount = (((SPWeb)((SPSite)SPContext.Current.Site).OpenWeb()).CurrentUser.LoginName).Split('\\')[1];
String basePersonalURL = "http://site:80/personal/";
String eventReceiverFeatureId = "12345678-1234-1234-1234-1234567890ab";
using(SPSite site = new SPSite(basePersonalURL + sAccount)) {
site.AllowUnsafeUpdates = true;
using(SPWeb web = site.RootWeb) {
web.AllowUnsafeUpdates = true;
try { site.Features.Add(new Guid(eventReceiverFeatureId)); } catch {}
web.AllowUnsafeUpdates = false;
}
site.AllowUnsafeUpdates = false;
}
}
</script>
You also need to edit the web.config file in order to allow inline code to run for this page. Hope this helps.
I am running a CMS web site on WSS 3.0.
I would like to have a custom sign-in page for the publishers. Do I have any other alternative other than the Welcome control? (For example, could I use ASP.NET Login control?
Thank you for your help.
That would depend on the authentication mechanism that you use. If you're using Active Directory, you're pretty much tied to the Welcome control.
If however you're using Forms Based Authentication, you can control to login page more completely.
FBA can be tricky to configure and I'd recommend staying with AD if you can, but if you have to go FBA, here's a good guide:
http://technet.microsoft.com/en-us/library/cc262201(office.12).aspx
This is really not much difficult.
It can only be happen if you have Forms based authenticated site not windows based, then you must have to modify login.aspx page.
this relies in _layouts folder of 12 hive. so you have to modify it.
Best way to do is, fo to _layouts folder, make a copy of it and paste it in somewhere in the disk and then change the location in IIS properties for the site of the _layouts folder to your copied one. and make the changes of that login page.
Points to remember.: It uses a master page and there are 5 or 6 customplaceholders requires. so do have them in your new masterpage.
Next is about the code behing for login control to work.
If you are customizing your login code. then you have to modify
this is an example :
using System;
using System.Web.Security;
using System.Web.UI.WebControls;
namespace CustomLoginPage
{
public class Login :
Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase
{
protected System.Web.UI.WebControls.Login loginBox;
protected override bool AllowAnonymousAccess { get { return true; }
}
protected override bool AllowNullWeb { get { return true; } }
protected void Login_Click(object sender, EventArgs e)
{
if (AuthenticateUser(loginBox.UserName, loginBox.Password))
return;
}
protected bool AuthenticateUser(string emailAddr,
string password)
{
string userName = emailAddr;
MembershipUserCollection coll =
Membership.FindUsersByEmail(emailAddr);
if (coll != null && coll.Count == 1)
{
// We're doing this to force the enumerator to give us the
// one and only item because there is no by int indexer
foreach (MembershipUser user in coll)
{
userName = user.UserName;
}
}
if (Membership.ValidateUser(userName, password))
{
FormsAuthentication.RedirectFromLoginPage(userName, true);
return true;
}
return false;
}
}
}
so please do modify it.
The one Url which i follow to perform this is :
http://www.devx.com/enterprise/Article/35068/1954
Go ahead and if you face any issues. feel free to contact me : ankurmadaan2787#live.in
The answers below are really helpful -but I'm afraid my environment is limited (WSS 3.0, shared hosting).
So I simply added this link which opens up the authentication dialog:
Sign in
(Where the Source parameter indicates the URL to redirect to upon authentication.)
Thank you.
I have a named site collection where FBA is on und i use ActiveDirectoryMembershipProvider.
We have a farm administrator domain\administrator. He is not explicitly sitecollection administrator.
I created a sample console application that I run under the domain\administrator account.
In the code is something like that:
using (SPSite site = new SPSite(serverUrl))
{
using (SPWeb web = site.OpenWeb())
{
Console.WriteLine(web.CurrentUser.LoginName);
Console.WriteLine(WindowsIdentity.GetCurrent().Name);
string userName = "domain\\testuser";
SPUser spUser = web.EnsureUser(userName);
SPGroup group = web.SiteGroups["GroupName"];
group.AddUser(spUser);
group.Update();
}
}
The console output is domain\administrator however I become an AccessDenied exception when I try to add user to the group.
However when I run this with RunWithElevetadPrivileges (which according to all posts I read should have no influence in console app) and set AllowUnsafeUpdates = true (the same story) the code goes smoothly through, no exception thrown and the user is added to the group. The interesting thing is that the user that is written to the console output is still domain\administrator.
So my question is: WTF? Is there a better way? Why is this happenning? Has anyone already had this problem? Should I use another membershipprovider?
Small hint: When the FBA is off I become no exceptions.
RunWithElevatedPrivileges runs code with permissions of user that the application pool runs. It can be other than Administrator. Are you sure you get the same result with RunWithElevatedPrivileges?
Anyway, a better, more reliable way of elevating privileges is to pass system users User token in SPSite constructor. Try it.
I'm trying to find out current user name for my sharepoint application. There are more that one way how to do this. However the sharepoint way returns misleading value.
System.Security.Principal.WindowsIdentity.GetCurrent().Name // returns MY_COMPUTER\\my_user
HttpContext.Current.User.Identity.Name // returns MY_COMPUTER\\my_user
HttpContext.Current.Request.ServerVariables["AUTH_USER"] // returns MY_COMPUTER\\my_user
Microsoft.SharePoint.SPContext.Current.Web.CurrentUser.LoginName // returns SHAREPOINT\\system
What is the cause of this behavior? Will I encounter problems if I'll use non-sharepoint way?
Are you browsing as the admin account that you used to install the system? SharePoint will "helpfully" rename that SHAREPOINT\System. Use a different account and all of the methods will return the same value.
This is expected if the user is the application pool account running the current web application.
BTW, it's supposed to be the same name as displayed in the welcome control (upper left control)
The problem is because you are probably getting the current user from an elevated SPWeb inside a RunWithElevatedPrivileges code. You can use the snippet below to get the real user
SPWeb site = SPContext.Current.Web;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite ElevatedsiteColl = new SPSite(siteColl.ID))
{
using (SPWeb ElevatedSite = ElevatedsiteColl.OpenWeb(site.ID))
{
string currUser = site.CurrentUser; //not the ElevatedSite.CurrentUser
}
}
});
This will show the real user name instead of the SHAREPOINT\System user.
I think you might have include this code under SPSecurity.RunWithElevatedPriviliges. Check it out once. I am not sure though
The other way SPWeb.CurrentUser could return SHAREPOINT\system is if the web is elevated, though I'm not sure why SPContext.Current would be elevated. On what kind of page are you seeing this behavior?