How to check if user has logged in to SharePoint Online or not from a web application?
An approach is search for cookies of SharePoint in local machine, but it throw a security problem.
Any solution?
I have found the solution, exactly a trick that come from jQuery.getScript()
Using a function that return a string, and place one in web page, one in a .js file and upload to SPO doccument library. For example:
This function put in local web page:
function whereAmI(){
return "local";
}
This function save in a xxx.js file and upload to SPO:
function whereAmI(){
return "remote";
Notice those two function have same name.
Then in local web page, insert the following code:
jQuery.getScript("https://xxx.sharepoint.com/sites/xxx/DocLib/xxx.js", function () {
if (whereAmI() == "local") // if not logged in, getScript failed to get xxx.js, so the page call local whereAmI
// do something;
});
That's it.
Related
I'm having a problem with a new xpages application that was deployed in production for a few months, but has now only been expanded to the entire enterprise now. The problem that did not happen while the application was in production pilot is intermittent and happens when an action executes a current notesxsppdocument save (currentdocument). The symptom is that by pressing the button you save, the document is not redirected and is displayed again. What can be this problem. session timeout, a bug from xpages? The application basically uses the components of the extension library, there is no external component to the xpages. When the problem occurs, if the user closes the document's xpages opens again and then clicks the button again the code runs successfully.
I have a function that stores a file attached to the doc in a repository. I suspect she's the problem. The function uses the file upload component and a button to execute a java agent that stores the file in a repository. The button code below follows. Its function is basically to create the rich text if it does not exist and call the agent that consumes a web service to transfer the file to a repository and erase it from the document.
I asked the user not to use the function for a few days at the time of the service to verify that the problem will persist.
if(validaArquivo())
{
var url=#ReplaceSubstring(context.getUrl(),"openDocument","editDocument")
url += '&tab=dossie' ;
var fieldItem:NotesItem =
currentDocument.getDocument().getFirstItem("arquivos");
if (fieldItem==null){
// create the field as an RTF
//writeToLog("Creating xxxxx field");
var rtItem:NotesRichTextItem =
currentDocument.getDocument().createRichTextItem("arquivos");
currentDocument.save();
}else if (fieldItem.getType()==1280){
//writeToLog("--> Converting xxxxx to RTF");
currentDocument.replaceItemValue("arquivosTEXT",
fieldItem.getText());
fieldItem.remove();
var rtItem:NotesRichTextItem =
currentDocument.getDocument().createRichTextItem("arquivos");
currentDocument.save();
}
var agente:NotesAgent=database.getAgent("(SalvaAnexos)");
agente.runWithDocumentContext(currentDocument.getDocument(true));
context.redirectToPage(url)
}
else
{
document1.removeAllAttachments("arquivos");
}
When users are using the application, rebuild or to change some code on prod environment can cause this.
I have a Nextcloud installation, with users stored in an external database, and this works fine with this app : https://apps.nextcloud.com/apps/user_sql
With that in place, I can login on my Nextcloud instance via the login form provided by Nextcloud.
I need to autolog the users when they come from another app.
I've written a PHP script, placed at the root of my Nextcloud installation, and it gets called by other internal apps of my company.
This script receives a userId and a token in the URL. After a successful check (no need to get in the details here), this script should log the user in.
Which API should I call to get the user logged in?
I tried the following, without success:
OC_User::login(...)
OC_User::getUserSession()->login(...)
Is there a way to trigger a valid login, so that I can get the users logged in?
Thank you for your answers, guys!
$user = '';
$pass = '';
$s = \OC::$server->getUserSession();
if (!$s->isLoggedin()) $s->login($user, $pass);
else $s->logout();
Placing this at /index.php and before calling OC::handleRequest() does the trick. It doesn`t work as expected but you could try to continue from here.
PD: Nextcloud Server v14.0.0 Alpha
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.
Our ASP.NET application pages are deployed as a feature into a MOSS 2007 farm.
When a user logs on to the site the user is directed to a default page.
In the top right corner there is an option "Log on as a different user".
If the user selects this option and enters the credentials of another user, an "Access Denied" message is displayed.
This message does not make sense since all the users have access to this default page. Furthermore, if the user now goes to the address bar and manually changes the URL to the default page, the page loads. I can see in the source part of the "Access Denied" URL that the encoded URL of the target page is the expected default page URL.
Previously, I made a change to the INIT.JS file to redirect the user in the case where the login change is done from a page that is not the default page.
function LoginAsAnother(url, bUseSource)
{
document.cookie="loginAsDifferentAttemptCount=0";
if (bUseSource=="1")
{
GoToPage(url);
}
else
{
var ch=url.indexOf("?") >=0 ? "&" : "?";
//url+=ch+"Source="+escapeProperly(window.location.href);
url+=ch+"Source="+escapeProperly(getSspLocation(window.location.href));
STSNavigate(url);
}
}
The original line is commented out.
The function getSspLocation is just a function I wrote to get the default page URL from any other URL.
function getSspLocation(url) {
var parts = url.split('/');
var result = "";
for (var i = 0; i < parts.length; ++i) {
result += parts[i] + "/";
if (parts[i].toLowerCase() == "ssp")
return result + "default.aspx";
}
return url;
}
Any ideas?
This will not answer your question, but I would advice you against modifying the init.js file. It is both against good practice and against Microsoft's recommendation, you will lose support from them. Furthermore, it will most certainly be overwritten when applying service packs and/or hot fixes.
If you have the need to customize the functionality of OOB script files, do so by deploying a custom master page that incorporates your custom scripts instead.
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?