Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

In some instances of WSS or MOSS when you use the "Sign in as Different User" option, the new login doesn't "take". Is there any known issue here? Usually logging out and then logging back in with the second user does work. This seems like a pretty big problem and I've seen it on and off over the years, mostly while testing with different identities.

UPDATE 1: I'm seeing it in several hosted WSS situations, so I don't actually know what authentication they are using. Interestingly, I don't see it in some hosted WSS situations, too. And consistently within the instance. This might tell us that the authentication method might matter.

UPDATE 2: Another piece of info I should have included in the first place: The reason that I'm asking this is that the $().SPServices.SPGetCurrentUser in SPServices sometimes returns the previous user. All I'm doing in that function is loading the _layouts/userdisp.aspx?Force=True page and pulling the Name from the page. It's the column with the label 'Account', but the InternalName is 'Name':

<!--  FieldName="Account"
             FieldInternalName="Name"
             FieldType="SPFieldText"
           -->

Here's the SPServices function:

// Function which returns the account name for the current user in DOMAIN\username format
$.fn.SPServices.SPGetCurrentUser = function() {
    var username = "";
    $.ajax({
        async: false, // Need this to be synchronous so we're assured of a valid value
        url: $().SPServices.SPGetCurrentSite() + "/_layouts/userdisp.aspx?Force=True", // Force parameter forces redirection to a page that displays the information as stored in the UserInfo table rather than My Site.
        complete: function (xData, Status) {
            $(xData.responseText).find("table.ms-formtable td#SPFieldText").each(function() {
                if(/FieldInternalName=\"Name\"/.test($(this).html())) username = $(this).text();
            });
        }
    });
    return username.replace(/(^[\s\xA0]+|[\s\xA0]+$)/g, '');
};

One would like to think that this page would always represent the currently logged in user, but sometimes it represents the prior user. Not good.

UPDATE 3: I may have come up with a fix for this in my SPServices library, at least. It doesn't solve the larger problem that SharePoint seems to have, though. I added a unique Query String parameter (just the current time) to the call to userdisp.aspx in SPGetCurrentUser per arunduttgp's suggestion. This seems to force the browser to do a hard refresh on the page in the AJAX call, getting the correct values for the logged in user even when the current SharePoint page is showing the prior user incorrectly.

 url: $().SPServices.SPGetCurrentSite() + "/_layouts/userdisp.aspx?Force=True&" + new Date().getTime(),
share|improve this question
    
Happens to me all the time too while testing. Usually refreshing the page a few times (+/- ctrl key) eventually gets the right identity going. I'm yet to find anything that gives an explanation and haven't had a chance to dig deeper. It almost seems like a credential caching issue of some kind. –  Paul Lucas Mar 24 '10 at 21:28
    
It happens to me a lot as well! One of the tests that I wanted to check was if it happens when the site is using kerberos, ntlm, or both. As we are only using kerberos I can't test that. Not sure if that would really matter. –  spevilgenius Mar 24 '10 at 21:54
    
In most cases I'm seeing it with NTLM, so that may eliminate that possibility! –  Paul Lucas Mar 24 '10 at 21:56
    
Does this happen with 2010 as well? –  MBSurf Mar 25 '10 at 14:51
    
I haven't worked with 2010 enought to know if it happens there, too. Anyone else? –  Marc D Anderson Mar 25 '10 at 16:02
show 1 more comment

7 Answers 7

I get this a lot, just not consistently. A page refresh will sometimes sort it out. I've taken to just using the "runas" command to avoid using "Sign in as Different User" and the associated issues.

runas /user:{Domain}\{UserID} [/savecred] "C:\Program Files\Internet Explorer\iexplore.exe [Optional URL]"

You can create shortcuts on your desktop to make this easier.

share|improve this answer
add comment

Just refreshing the page is not enough, the majority of times this is simply due to browser caching but a page refresh will not refresh the browser cache.

In IE you would click Cntrl + F5 to clear the cache and do a full refresh, not sure what the same command would be in FireFox or other browsers but the concept will be the same.

share|improve this answer
    
Charles I don't think its a browser caching issue. If there has been content changed on the page, I see the new content. It's just that the logged in identity does not change until the page has been refreshed a few times –  Paul Lucas Mar 25 '10 at 12:20
    
Apologies I only read the question briefly and it read like an easy fix. I see it in more detail now, although its not something that I have seen before. –  Charles Lee Mar 25 '10 at 19:13
    
No worries, Charles! I wish it were as simple as a refresh. –  Marc D Anderson Mar 25 '10 at 19:27
add comment

I see Paul's comment above about seeing the issue more with NTLM. I run Kerberos in the vast majority of my environments, and I very rarely see it at all, so it could be the case where it's related to NTLM.

It's got to be some sort of cache either within the browser or the session. I wouldn't think that there's a way to force a refresh through the script, unless you can refresh the destination URL before reading from it.

share|improve this answer
add comment

I don't necessarily have a solution for you (other than the "refresh the page a couple times" others have mentioned, but as a data point I only started seeing this behavior when I first upgraded to IE8. In fact on machines where I still have IE7, I never see it at all. I'd be curious if others share this experience.

share|improve this answer
    
I think you're right about IE7... I've never seen it happen with IE6 either! LOL. –  Paul Lucas Mar 26 '10 at 20:11
    
Although I have seen it with FireFox 3.6 –  Paul Lucas Mar 26 '10 at 20:13
add comment

A more dependable way to determine the logged on user may be to just ask the server instead of going through SharePoint ( which at this point is acting as a middle man). Getting the variable directly may help with the whole refresh question as there may be some lag as the credentials are updated, guessing here.

This page should help. Specifically, the LOGON_USER variable will have the value you need.

share|improve this answer
add comment

I'm dealing with same issue of login as Different user not refreshing the page to show the new user and that users permissions. Usually though (Firefox) after a page refresh the correct user and permissions are showing.

But I think a related problem is that if a user lands on the AccessDenied.aspx page and attempts to logon as a different person (using the provided link) it seems to have a similar failure of not updating with the new users permissions and such. Only workaround is to have users close all browser windows and start over by logging in with the correct credentials.

I don't know if this is a new shortcoming of using Windows Integrated Auth and updated browsers holding onto previous credentials or what.

share|improve this answer
add comment

I like Clayton Firth's solution, using the "runas" command. Any way to make it prompt for the user? Also, can I run this command from a link within SharePoint? Essentially I would like to replace the "Sign in as Different User" menu option witht the "runas" command.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.