I am trying to access a Windows Media Player library from ASP.NET.
The following code:
WMPLib.WindowsMediaPlayer mplayer = new WMPLib.WindowsMediaPlayer();
WMPLib.IWMPStringCollection list = mplayer.mediaCollection.getAttributeStringCollection("artist", "audio");
Returns an non-empty list when run using the VS2005 development web server but an empty list when using IIS.
Setting impersonation with:
System.Security.Principal.WindowsImpersonationContext impersonationContext = ((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate();
Doesn't help. It seems that WMPLib still doesn't thinks its running as a user who has a library.
Is there a way to get around this?
Have you tried configuration via web.config in ASP.NET? When you're running in the VS2005 debugger, you're (probably) running code as yourself, but when under IIS you'll be running it as IUSR_machinename or another low-permission system account.
Try adding something like this to your web.config file:
<system.web>
<identity impersonate="true" userName="MYDOMAIN\myuser" password="p#ssw0rd" />
</system.web>
No idea whether this works with Media Player specifically, but it works for other identity/security related problems like this.
I've run into a similar problem: the code works fine on my local machine, but once deployed on my home server, it can not pull anything out of the media library (I can open media player to verify there are songs in the library)
At first I thought it was a process issue as well, so I tried both setting the application pool to run under my own account, and to set it via the identity impersonate tags; neither resolved the issue.
I'm not sure of what other differences would cause the issue
Related
I've developing an asp.net core application to tun on a web far, and I'm using "AddDataProtection" to protect for key encryption at rest like, the documentation recommends, but when I deploy my application and run directly from IIS with AppPool identity, the key is never created and I get errors on the DpapiNG windows logs.
My code is the following:
services.AddDataProtection(opt => opt.ApplicationDiscriminator = ApplicationConfig.dataProtectionApplicationDiscriminator)
.PersistKeysToFileSystem(new DirectoryInfo(encKeyPath))
.ProtectKeysWithDpapiNG(string.Format("CERTIFICATE=HashId:{0}", ApplicationConfig.dataProtectionCertThumbprint),
flags: DpapiNGProtectionDescriptorFlags.None);
Debugging from visual studio, everything runs fine, but I'm running VS under administrator rights, so permission is not an issue here.
I've tried adding permissions to the AppPool App user to the private key it self directly from MMC, but it did not worked, and even gave permission on the full path to the location were the keys should be created like stated here https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview (check first comment) but also it did not worked.
I was only able to make it work by setting the AppPool to run with the identity of an Administrator, but clearly this is a no go, I just wanted to make sure this was a permission issue somewhere.
Is anybody facing the same issue that is able to help?
Regards,
André
Most likely your issue is you are trying to store your keys somewhere in a folder path that you are cobbling together (or even by using the default path that AddDataProtection provides) that uses an environment path such as %LOCALAPPDATA%. Example: "%LOCALAPPDATA%\ASP.NET\DataProtection-Keys".
Usually, by default IIS DOES NOT set up your app pool accounts with environment path variables such as %LOCALAPPDATA%. The value ends up being blank and your app then tries to write keys to the wrong folder (such as \ASP.NET\DataProtection-Keys instead of %LOCALAPPDATA%\ASP.NET\DataProtection-Keys).
Fix: Within %WINDIR%\System32\inetsrv\config\applicationHost.config set setProfileEnvironment=true. I think you have to restart IIS as well.
I have a deployed a web application in IIS. Which used to work without any issues. Recently i have shifted that web application to another machine, Here is the problem. Once i setup the Webapplication when i opened the default document in IIS im getting the File not found error as following
Internal Server Error
\?\C:\inetpub\wwwroot\application\web.config
I have no clue why the IIS is not able to find the web.config. The file is present in the path C:\inetpub\wwwroot\application\web.config but the IIS is looking in the path \?\C:....
Please let me know how to resolve this??
Firstly this is documented on support.microsoft.com so I would suggest that anyone who has this issue read this first as it covers a number of solutions which I won't
Now from personal experience I encountered this error after setting up a new development machine. What I had forgotten to do was install the Url Rewrite 2.0 IIS module. Sadly the IIS error gives absolutely no idea that this is the actually issue.
Therefore to solve this issue investigate the system.webServer setting in our web.config and ensure that you have installed all the iis modules that you use. I did this by systematically removing elements from my web.config until I came across the cause.
In my case, I was running ASP .NET Core website so I had to install .Net Core Runtime from
https://dotnet.microsoft.com/download/dotnet-core/current/runtime
I know it's old post but I resolved the same issue as follows:
If you are using TFS and you are getting this problem then Reason is ".vs" file is not excluded from commit.
Because of that ".vs\config\applicationhost.config" gets the local version of another user/Developer.
To Solve the error, First open that file Update Physical path inside "" xml tag.
Also ask user to exclude this folder from TFS to prevent future issues.
If you are getting mysql localhost error. What I will do will work for you.
Control Panel(View by: Large Icons) >> Programs and Features >>
(Usually upper left corner) Turn Windows Features on or off >>
Internet Information Services >> Web Management Tools and World Wide Web Services
After Restart.
I have a strange problem when trying to get the application pools on the current machine. It seems that when IISExpress is installed, the Microsoft code wants to check IISExpress in addition to the full IIS. IISExpress uses separate applicationHost files per user. I'm not sure whether this call will require it to check all of those, or just those for the current user. Regardless, it's not finding the one it's looking for in the 'C:\Windows\system32\config\systemprofile\' directory. It should be going to %userprofile% or 'C:\Users\Administrator\' for the user that the application pool that this code is executing under is running as.
Does anyone perhaps know how this systemprofile directory might be coming from?
Exception:-
System.IO.DirectoryNotFoundException: Filename: \\?\C:\Windows\system32\config\systemprofile\Documents\IISExpress\config\applicationHost.config
Error: Cannot read configuration file
at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
at Microsoft.Web.Administration.ServerManager.get_ApplicationPoolsSection()
at Microsoft.Web.Administration.ServerManager.get_ApplicationPools()
at CustomCode.Classes.IIsApplicationPool.GetApplicationPool(String iisWebSitePath, String poolName)
I highly recommend to stop using the local reference to Microsoft.Web.Administration that gets shipped with IIS (even if it's in the GAC). This is because it has a very specific version number (i.e. 7.0.0.0) and this version might change in a future version of Windows and it will hurt.
Instead, checkout the nuget package: Microsoft.Web.Administration (https://www.nuget.org/packages/Microsoft.Web.Administration). This basically makes it so you can have a private deployment of your IIS dependencies.
If the application, in which you are using Microsoft.Web.Administration to check for app-pools, is running on IISExpress, it will always fallback to Microsoft.Web.Administration version 7.9.0.0 due to an assemblyredirect in the aspnet.config in the IIS express.
See C:\Program Files (x86)\IIS Express\config\templates\PersonalWebServer\aspnet.config
Here is the problem in the config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Web.Administration"
publicKeyToken="31bf3856ad364e35"
culture="neutral" />
<bindingRedirect oldVersion="7.0.0.0"
newVersion="7.9.0.0" />
<codeBase version="7.9.0.0"
href="FILE://%FalconBin%/Microsoft.Web.Administration.dll" />
</dependentAssembly>
Make sure you are running the application in either the full IIS or on the Visual Studio Development Server.
Alternativly you could try and remove the assembly redirect, but i have not tried this, and this might cause problems in other places. We must assume that the IIS Express team made the redirect for some reason (other than convenience) :-)
I already know the answer is old but
have you tried specifying a different version of the dll?
A picture is worth in thousand words:
How are you trying to get the application pools? Are you using MWH (Microsoft.Web.Administration) APIs?
Full IIS ships with Microsoft.Web.Administration.dll (version 7.0.0.0).
IIS Express ships with a different version of Microsoft.Web.Administration.dll (version 7.9.0.0).
It seems full IIS is trying to use IIS Express specific assembly. I am not sure how you ended up in this state, but you can un-install IIS Express and see if this problem still occurs.
Edit:
Why do you want to use Microsoft.Web.Administration (MWA) version 7.9.0.0 in your web application? It is shipped with IIS Express 7.5 to work with per user applicationhost.config file ONLY and this does not use/work with inbox/full IIS configuration file that is located at \windows\system32\inetsrv\config\appliationhost.config.
In your case, web application running under full IIS is running with system identity and therefore MWA 7.9.0.0 is trying to load config file from 'C:\Windows\system32\config\systemprofile' directory.
I've just recently ran into this issue. After reading quite a few posts, this was the closest one at giving me any idea as to what was going on. While I don't necessarily have a solution to the conflict between the two versions (7.0.0.0 and 7.9.0.0) when running within the VS IDE, after a few hours struggling with it, I did find a of quirky trick you can do to work around the IDE's auto-redirection.
In the example of:
Developing an application that's referencing Microsoft.Web.Administration.dll (7.0.0.0) from the inetsrv directory and attempting to do any of the following and trying to connect properly access the application pool definitions of the real IIS, not IIS Express, with not installed. When running the compiled code outside the IDE, it always works correctly regardless of how it's specified.
ServerManager sm = new ServerManager();
sm.OpenRemote("localhost");
sm.OpenRemote("MYPC"); // Presuming you local machine's name is MYPC
These all trigger VS to redirect the reference from the 7.0.0.0 DLL to the 7.9.0.0, which causes the retrieval of incorrect sites or COM exceptions to occurs.
The quirk I found was to always use the OpenRemote(), even though trying to open the local IIS and specify "localhost" or "MYPC" as either "LocalHost" or "MyPc" (i.e. any combination of mixed case so that it is not an exact case-sensitive match to "localhost" (all lower case) or the local machine name.
This quirk may not be specific to all VS versions. I'm currently using VS Professional 2017 (15.9.11).
As I stated, it does fix the redirect, but it definitely help while debugging.
I found mapping the "TeamConfig folder" locally to my development machine helped resolved this issue for me.
I've got a classlibrary which defines a couple of helper classes/methods which are used from a classic asp web application. So far, everything works fine. Now I've added a new helper method which signs a PDF file using a third party tool. Using a console application to call this wrapper method, everything works fine. Once I use an asp page to call the exact same method, the call to
X509Certificate2 cert = new X509Certificate2(sigFilePath, sigPassword);
fails with the error "The system cannot find the specified file" (translated from german).
Since the same code works fine called from the console application, i guess the problem must be located somewhere different. Could it be a security issue?
When I wonder if I'm facing a security issue like you do, I just do a quick test : I put the user account the webserver is using in the administrators group, do a quick iisreset, and try again. If it's working know you now it's a security issue. If it's still failing, look somewhere else.
Never forget to then remove the user accoung from the administrators group, and only do that on you own dev machine, not on production servers !!
If it's a security issue, I would then recommend launching Process Monitor (look for procmon in google). It's a Microsoft download. Look for access denied in the result column. You'll then know what's blocking you ...
I'm trying to write an HttpModule to run on our SharePoint farm - essentially it will check whether the user is authenticated and if they are it will validate some info against another database and potentially redirect the user to sign a variety of usage agreements.
Whenever I enable the module in the web.config I'm finding that SharePoint has issues rendering the page - it's almost like the CSS is not getting loaded as the page is devoid of any styling.
As a test I've even tried an empty module - i.e. an empty init block so it's not even hooking up any code to any events and the same issue arises. At this point it's an empty class that just implements IHttpModule so it's not even my dodgy coding causing the issue!
The module is in a class library that I've dropped in to the bin folder of the application it needs to run against. In the web.config of the app I've simply added an entry as below:
<modules runAllManagedModulesForAllRequests="true">
... (default stuff ommitted)
<add name="SharePointAUP" type="SPModules.SharePointAUP" />
</modules>
I must be missing something really obvious here as I've done exactly the same as every sample I've found and yet I'm getting this strange behaviour. Is there something extra I need to do to get SharePoint to play nice with a custom module?
UPDATE:
In case it helps - this is SP 2010 beta running on Windows 2008 R2.
UPDATE:
The set-up I'm running against is a farm - 2 front end servers with NLB & 2 app servers with services split across them.
After listening to a nagging feeling this morning I've tested my handler on another installation we have which is a standalone set-up... and everything worked perfectly. The issue only exists when deploying to a farm.
make sure to include a precondition attribute
I came back to this after reinstalling the farm with the RTM - everything worked fine. I've written it off as beta issue (along with many others that I had with SharePoint if you've seen my other questions!).