I have build one employee directory webpart that gets necessary information of user from sharepoint site. i have deployed in my testing server "Windows Server 2003 and Moss2007" and it's work fine.
When i tried to deploy on my production server "Windows Server 2008 R2 with Moss2007". It give me security error.
Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed."
I have also created security policy file and added reference to web.config. Still i getting same error please help on this. i am stuck here and not able to find any way to get out of this.
Thanks in advance.
Do you install your DLL into GAC? You must either install it into GAC (the solution does it for you if you specify the assembly location as GAC) or provide a custom CAS policy and register that policy in the web.config file. We usually prefer the first way, unless a customer specifically requires a custom CAS policy. This is much easier and I really doubt the security-wise effectiveness of the custom policy approach (unless your IT department actually goes over your code and examines what it can and cannot do, haven't found a department that would know how to do that)
Related
I have tried multiple ways to get the production SharePoint content to my newly installed local development environment that is running on a VM Windows Server 2008 R2. After an export of the farm and a restore failed I came across this blog post and followed these instrucitons: http://richardstk.wordpress.com/2012/02/03/build-a-sharepoint-2010-development-test-environment/. To sum up, it's basically backing up the live SQL Content database as well as the Profile, Sync and Social databases, then restoring them on the dev machine and pointing SharePoint to use these new databases instead of the old ones. Then after that I deployed the custom webparts to the development server from within Visual Studio.
I've done this and it seemed to work pretty well. I can access Central Administrator as well as setting up a SharePoint Connection within Visual Studio and being able to see all the pages, lists, documents, etc. So it is definitely pointing to the new content database. I should mention I can also connect via SharePoint Designer and access all the correct content, Master Pages, lists, etc.
The problem I am having is that I am getting a "Could not load file or assembly" error when I go to the site in a browser and it takes me to /Pages/Home.aspx. The file is a custom webpart that I have deployed from within Visual Studio. When I look within the GAC I see the assembly listed but the PublicKeyToken is different from the one that is shown in the error message.
When I dig into it a little more I see that the custom user control is registered in my Master page, and when I look at the ascx file in the _controltemplates directory where it is located there is an Assembly that looks like this:
<%# Assembly Name="BlogRoll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=529e9730fe2a198d" %>
That PublicKeyToken is correct for the live site when I look in the GAC there but when I deployed it to my local GAC it created a new PblicKeyToken. Sorry if I'm rambling but I wasn't sure what was relevant and what wasn't.
I guess my question is how to handle this? It doesn't seem smart to change all the ascx files locally to match the new PublicKeyToken's that I have in the local GAC because then when I deploy these changes to live they won't find the appropriate assembly. What is the best way to handle this?
UPDATE
The code in question has a key.snk file that is being used to strongly sign it. My understanding is that this should make it so that it gets compiled with a specific PublicKeyToken each time and therefore install in the GAC with a specific PublicKeyToken. If that is true, then I believe the only reason it would have a different key token on my dev environment versus the production is that the key.snk file that has been provided is incorrect. Is that true?
You could use WSP Builder or WinGac to forcibly deploy the assembly with the correct PublicKeyToken to your local GAC.
I deployed some solutions to Sharepoint Central Administration.
After this, the Central Administration can't open. this error appear when I try access the site:
Error
Could not load file or assembly
'Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The
system cannot find the file specified.
I saw at some blog this error occur because the solution isn't compatible with sharepoint foundation.
So I uninstalled all solutions from site using PowerShell's Command. But the error persist.
What I need to do to fix it?
I assume you only have SharePoint Foundation installed since you get this error, (and not SharePoint Server).
I would check the web.config of the central admin website for references to 'Microsoft.SharePoint.Publishing'. Probably the custom solutions you installed left some traces there and that's causing your problem. It's not pretty but you'll probably need to remove these references manually.
Howdy all. I am trying to solve a problem which is apparently not uncommon and I'm not sure how to find how this was resolved for folks. When I run StructureMap on my machine through IIS I get an exception and it looks like this:
**Description**: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.
**Exception Details**: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
This question has come up here at SO (https://stackoverflow.com/questions/784666/), in the comments on this blog post and a year or so ago on the structuremap mailing list.
My problem is not running it in a foreign hosting environment. I can't even get it to run on my own box (IIS 7.5, Win7 RC, .NET 3.5). I have tried to configure the site to use a custom policy file and the FileIOPermission is marked to have unrestricted access...no dice. If anyone has some tips or a link it would be greatly appreciated.
Update
So there is no way that this is the best way to solve the problem, but after digging around and looking into what Joshua mentioned, these are the things I had to do to get it working: StructureMap, Code Access Security and a Bad Solution to a Problem. A better solution would be appreciated.
For what it's worth, I ran into this same issue where I had full control over the box and even set all the permissions to full trust. With IIS 7.5, I had to change the identity used for the specific application pool to NetworkService instead of ApplicationPoolIdentity. Once I restarted IIS, it worked.
FYI, I'm using StructureMap v2.6.1 and ran into this issue.
I do not use an XML configuration, so I added the following line to my configuration code, which fixed the problem.
IgnoreStructureMapConfig = true;
This is a bug, and has been fixed in the trunk. It will be included in the 2.6+ releases.
Some earlier versions of StructureMap would either attempt to unnecessarily write the dynamic assemblies to disk, or unnecessarily attempt to read from the filesystem.
If you are running in a restricted environment that does not allow access to full paths in the filesystem (ASP.NET), make sure to set IgnoreDefaultFile = true when you configure your container. Keep in mind this will disable the ability to load XML configuration from StructureMap.config.
Using the official StructureMap 2.5.4 build on Windows 7 with IIS 7.5 I still encountered this problem.
Mallioch's change
ObjectFactory.Initialize(x =>
{
x.UseDefaultStructureMapConfigFile = false;
x.IgnoreStructureMapConfig = true;
was necessary to resolve the FileIOPermission exception but I then received Request for the permission of type ‘System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed. which I resolved using Mike's solution ( for which I've created a step-by-step visualization ).
I created a code behind file for a custom master page in visual studio. I hooked everything up manually; safe control and custom cas policy. Everything works great!
I then wanted to put this into a sharepoint solution using WSPBuilder for better deployment. I created WSP solution, added my class file and changed the output directory to the bin folder. I then built the solution and deployed it, making sure to change the page directives on the master page to reflect the new assembly name.
Now when I go to view the sharepoint site I get an error stating Security Exception error stating
‘Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.’
This has me stumped as it works as a visual studio class file deployed to the bin directory of the website.
However when I put this into a sharepoint solution it breaks! I tried adding
‘[assembly: System.Security.AllowPartiallyTrustedCallers]’
to the AssemblyInfo.cs but this hasn’t helped.
Anyone else experinced this or have any advice?
EDIT: I should also mention that the code behind is trying to access a sharepoint list.
Don´t you still have to include the SafeControls entry in order for it to work, like:
<SafeControl Assembly="[FullAssembly Name]"
Namespace="[YourMasterPageNamespace]"
TypeName="*"
Safe="True" />
or in WSPBuilder config:
<add key="BuildSafeControls" value="True" />
Never seen this.. but I suspect not many people have created codebehinds to the master pages in SharePoint (Microsoft doesn't too!).
I don't know what you are trying to build but I'd probably implement it using a server control that is included on the master page.
AllowPartiallyTrustedCallers has always fixed it for my server controls.
What is the trust in your web.config file set to? Try Full.
Are you calling a third party assembly?
I ran into a situation recently that I was using a third party assembly and it did not have AllowPartiallyTrustedCallers in its code. When I tried to use the assebmly, it would fail.
Are you sure that the assembly has been deployed to bin and no to GAC by accident? If there are two assemblies the one in GAC takes precedence.
You might try checking that you are using the fully qualified five part name including the correct public key token and namespace for your assemblies.
I have deployed a web site to a Win 2008 Web server with IIS7. The site works fine on a Win 2003 Standard server with IIS6. On the 2008 box, whenever I request a page (htm or aspx) from a folder named Reports, I get challenged with the Windows Authentication dialog box.
I have Anonymous Authentication and Forms Authentication enabled on the site. I applied Full Control permissions to the root of the site for both NETWORK SERVICE and IIS_IUSRS, but that hasn't make a difference.
Like a previous post already mentioned, here are the detailed steps to fix this:)
If there is a folder in the application named "Reports" and SQL Server Reporting Services are installedon the server, then Reporting Services Virtual Directory folder that is also named "Reports" will be in conflict with the application "Reports" folder.
To fix this open Reporting Services Configuration Manager (Start->All Programs->MS SQL Server->Configuraton Tools) and change the Virtual Directory under the "Report Manager URL" in the menu on the left.
Did you install MSSQL Reporting Services on your new machine? It'll use the Reports folder for the reporting toolkit (default setting) and under MSSQL 2008 you can't enable anonymous Access out of the box.
whats is the authentication mode in your web.config, verify that is not in Windows
<authentication mode="Windows" />
also be sure to disable integrated windows authentication in iis
You could try running FileMon from SysInternals to see if it is the file system that is sending back the "access denied".
Quote from another forum that solved this issue for me:
"SQL Server Reporting Services creates a folder called Reports by default if you install it on IIS. If you install SQL 2008 then Reporting Services doesn't need to use IIS and instead will try to reserve the URL with the HTTP.Sys service.
I believe this is the cause of the conflict you are seeing. What you could try is changing the URL that Reporting Services uses via the SQL Server Reporting Services Configuration Manager."
Well speaking on the same subject here, yesterday I was deploying my application on Windows Server 2008 running IIS7 w/MSSQL 2008 on there too. In my website's tree structure I had a folder named Reports that had a subfolder in it, and then the actual pages. It looked like this "Reports/SalaryReports/SalaryReport.aspx" The interesting thing was that when I clicked on a hyperlink to go to "Reports/SalaryReports/SalaryReport.aspx" I got a username/password prompt from my server. This did not happen on the VS development server when I ran the application on the development machine. So I was like hmm? I looked at the code-behind in SalaryReport.aspx and did not find anything unusual. So then I put a Default.aspx directly in the Reports folder (thinking maybe it was something wrong with the authentication going two nodes down from the root to get to SalaryReport.aspx) but the server still requested username/password even though there was no security settings applied to this new Default.aspx. So I figured it must be that the folder is named "Reports", so I renamed it to "Reports1" and bigno! Everything worked!....I will still look further in this issue today, but it seems that either an IIS 7 HttpModule (not one of mine) is trying to "reserve" the folder that is named "Reports" for itself or something else...I'll look into the SQL Server Reporting services as the above post mentioned...
Anyways, just wanted to share:)
I'm supposing you don't have a SQL Reporting Services running on the same server:
1 - Give rights to user "IUSR" and the user that's running your application pool.
2 - Overwrite child folder permissions and ownership.
2 - Check if there's a web.config file on that folder setting different access rules.