I've researched these other two threads that I thought might be related but there issues is different:
Why does IsInRole always return false?
IsInRole problem
I'm checking against a role (string) "DomainName\Booking Reader" for Context.User which I verified exists via CMD window running "net user theusername /domain" which returns a list of Global Group Memberships where "Booking Reader" is in that list.
However when I step thru my code Context.User.IsInRole("DomainName\Booking Reader") it returns FALSE?
This ONLY happens when I'm debugging from within Visual Studio 2022, when I access the production website from my dev PC my role is working correctly.
I had no issues with VS 2022 debug sessions about two weeks ago when running on the same PC but under Windows 10 ... I recently upgraded to Windows 11 and now I have this issue.
Very puzzled? Any suggestions?
Related
I have a Windows 2012 R2 Standalone Root CA setup to issue authentication certificates when requested via the certrqma.asp page. This page has been modified to only show a small number of fields required but no configuration has been changed over the default and has worked fine in the past, however, recently (Not exactly sure when) the page simply won't submit the request.
I can see errors via the console in both IE and Chrome but the user feedback on form submission is to display the message:
This page has not finished loading yet. Please wait a few seconds and try again.
IE Console: SCRIPT5009: 'GetCSPList' is undefined - certrqma.asp (1523,3)
Chrome Console: Uncaught ReferenceError: loadXEnroll is not defined at postLoad (certrqm.asp:997) & at onload (certrqma.asp:9)
My ASP coding is non-existent and am feeling my way along but at least found the above so hoping it's useful detail. Any ideas?
So it turns out, this is a direct result of Microsoft disabling, by default, the execution of VBScript in IE11 onwards. This was changed in the August 2019 Windows Security Update and has been planned since early 2017: An update on disabling VBScript in Internet Explorer 11
VBScript can easily be re-enabled in IE using one of the methods in Option to disable VBScript execution in Internet Explorer for Internet Zone and Restricted Sites Zone but compromising security is not something we should have to ask clients to do in order to use this as intended.
I thought the Windows 2019 Server version of this form would be coded differently to address this seeing as disabling it has been in the pipeline for so long but is not the case as 2019 Server Certificate Services Web Enrollment still requires VBScript in order to use this form.
Locally installed TFS2013, VS2015 and VS2013 using SharePoint services.
So far the development system is kind of OK, meaning I can create a collection, create a team project within a collection, add a new solution to that, run it, do a Check In and the SharePoint site shows the project code, etc. I can also create work items at the SharePoint site and from within Visual Studio.
But I'm having difficulty understanding how the user accounts are interacting. On my development workstation I logged in with a normal domain account. But I do not see work items assigned to that user name. I only see work items if they are assigned to the system Admin account.
I would have expected VS would be operating under the user account that I logged into Win10 with, but it seems to be operating as though VS is logged in as the system Admin.
Why is that? Is there a place where VS sets data that tells TFS what user name it is operating under? And, of course, I may be asking the wrong question because I don't understand the problem, but this is how it appears.
Added after initial post for clarity
This panel shot shows where the Work Items were not showing up for the user under Available Work Items. Because of the issue identified in the answer below, only work items assigned to Admin were present. But after clearing the cached credentials the work items displayed correctly according to the proper account, no longer acting as Admin.
This may due to the VS had cached your system Admin account.
The simplest way is to delete the related credentials which stored in control panel > Credential Manager> Windows Credentials
Then reopen the VS and try to connect to TFS server. It will pops up a credential window, just type your login domain account.
I initially installed the Microsoft Visual Studio Express 2013 for Web on my desktop. My desktop runs Windows 8.1 with internet explorer 11. It ran fine until the license expired after the first 30 days. I tried to sign in to renew the license, however after clicking the 'sign in' button I get an error dialog. The dialog states 'Browser is security restricted or javaScript is disabled. I have no other option but to close and exit Visual Studio.
I went to the online forums for Microsoft. There were discussions and suggestions on how to fix the error. I tried lowering the settings for the security tab in internet explorer. I have validated the option for scripting is enabled. I have also added https://*.visualstudio.com to the trusted sites tab. Other users on the forum have tried the same suggestions and have not succeeded in signing into the visual studio application.
I had exactly the same problem, here is what I did:
a) Go in IE, click on settings wheel then Internet Options and Security tab.
b) Click on Custom level button (make sure you select Internet zone).
c) In Security Settings window, under Scripting I set Enabled for Active scripting.
After that Sign In should work. Even though Chrome is default browser, it seems that VS uses IE for sign in process.
Hope this helps!
There is another issue people are running into that is a bug with the login dialog. The login dialog is using a Web Browser control to login the user. By default it loads up "about:blank" as the URI. It then proceeds to try to execute some JavaScript (just ";") to verify it has permissions to do so. On some machines this is problematic because "about:blank" has been mapped to zone 0, or the Local Machine zone. When the JavaScript is executed MSHTML will check the zone of the URI and then the policy for executing scripts. By default the Local Machine zone is locked down, and all script executions result in a Query policy. What this means is if you're running in immersion mode (aka in Internet Explorer) you will get a message box asking if you want to execute the script. However, the Web Browser control used by VS 2013's "Sign In" dialog doesn't run MSHTML code in immersion mode, so the Query policy effectively equates to a Disallow policy. The bug here is someone in VS assumed "about:blank" resolves to the Internet zone, and when it resolves to the Local Computer zone you get this behavior.
The workaround is to remove "about:blank" zone mapping. Point regedit to this key:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains]
Remove the "blank" key.
Alternatively you can change the Local Machine Lockdown policy for executing scripts. The reg key for that is:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones\0]
Set the "1400" DWORD value to 0.
There are many sites you need to list in your Trusted Sites. Following the trace of what the stupid, stupid login script does:
https://.visualstudio.com
https://app.vssps.visualstudio.com
https://.accesscontrol.windows.net
https://auth.gfx.ms
https://login.live.com
Only then was I able to log on to my FREE software.
Hi this is Albert from Microsoft. Just want to let you all know that this issue has been fixed in the upcoming Update 2 for Visual Studio 2013. Thanks for your patience while we figured this one out :)
Same problem "Browser is security restricted or JavaScript is disabled" here but the solution from #jic didn't work for me..
If you can and it is convenient for you this is a solution which worked for me:
I have created a new user/profile on my PC and for this user it was just working fine.
Before this action I have tried to make an user account which had this problem as:
Power user - didn't work
Administrator - didn't work as well
So the last solution in my case was a brand new user on the PC..
Here's what worked for me.
Open Control Panel, Internet Options.
First, I clicked the Security tab and turned security the security for the Internet zone to its minimum.
Next, click the Privacy tab, then click Advanced. Choose "Accept" for both types of cookies.
Of course you can change these all back after extending your VS trial.
you must change secure settings of iexplore for admin account. If logon by other account, you must start iexplore under admin account or logon under admin account, because you will get license after admin account.
Click on Start --> Run --> type cmd and click on OK.
Command Prompt will be opened. Then enter this command.
ipconfig /flushdns
and press Enter.
Now try to access https://app.vssps.visualstudio.com/Profile/View
It worked for me...
As I can not add a comment yet to the answer of CBGraham, I've to add this note over here:
The solution described from CBGraham worked for me (Thanks Graham). I had to add an additional link:
https://account.live.com
Then I opened the IE and tried to login to a Microsoft site. I left the IE window open and just clicked once again on the VS to login. Then it worked for me. Even with strong restrictions on the IE settings. While I'm surprised why someone should set down his security settings, just to register VS.
I'm testing out a mailbox connected to exchange, exchange version 2010 outlook version 2010 cached mode on. The exchange is offline in this scenario or there's connection issues.
If I use the following method
RDOSession.Logon 'Blank parameters
I will get a MAPE_E_FAILONEPROVIDER error when I retreive folders. However, if I use
RDOSession.Logon ,,True,True 'Prompt to choose the profile
Everything process normally. The behavior that I want is as follows:
If the user select "Always prompt" for a profile to choose, I want the code to prompt. If the user select a default profile, I want the code to run silent and select the default profile. I also want both options to run flawlessly when cached mode is on and there's connectivity issues.
How can I solve this?
Thanks!
Alright, I solved part of the question by myself. I'm checking this key:
HKCU\Microsoft\Software\Exchange\Client\Options\PickForProfile
and use different logon method depending if it's true or false. But this does not solve error that I'm having when the user does not pick a profile.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html