Working locally the css and images are loaded in pdf correctly. But as soon as i migrate code on the server, these are not loaded in the generated pdf.
I am using ViewAsPDF(). There are some partial views in my code so I cannot use Server.Map.
Would really appreciate your help.
Regards
Old post I know, but hopefully can help someone in the future.
This situation can occur when your site uses windows authentication.
You need to give access to your CSS files in the web.config as follows:
<location path="content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
You need the Rotativa folder in the root of the web app, or if different provide the path in web.config.
I had the same problem, fixed up by service account or server logon user name and password on ViewAsPdf customswitches.
eg.
return new ViewAsPdf("PdfInvoice", model)
{
CustomSwitches = string.Format("--username \"{1}\" --password \"{2}\" --footer-center \"Page [page] of [toPage] - {0}\" --footer-font-size \"8\" ", "Receipt Number :" + model.ReceiptId.ToString(), serviceAccountUsername.ToString(), serviceAccountPassword.ToString())
};
Related
Im trying to use elfinder in my MVC 3 application and using this .NET connector
: http://elfinderconnectornet.codeplex.com/ for elfinder. And this connector works with http handler configured in section in WebConfig. For example:
for url like :
192.168.0.17:9002/elfinder.connector?_=1347370006351&cmd=open&target=&init=true&tree=......
i have a handler in web config
<system.web>
<httpHandlers>
<add verb="*" path="elfinder.connector" type="ElFinder.Connector.Connector" />
</httpHandlers>
</system.web>
and in global.asax.cs routes.IgnoreRoute("elfinder.connector");to ignore this url in "Controller/Action" routing.
When im running this code in VisualStudio localhost all works fine but on IIS 7 i have an 404 error.
May be IIS have custom config for httphandlers? some checkbox need to be checked :)
Any idea?
I received the same error because I didn't have read permissions on the directory. You must give, at least, read permission to see the folders and files.
Hope it helps. Regards.
I currently have a ASP.Net MVC web application that needs to upload large files using ajax. I am currently using this jQuery plugin - http://valums.com/ajax-upload/. I have also used this plugin - http://jquery.malsup.com but get the same result.
The issue that I am having for large file is that the iframe that gets generated to in order for the request to be asynchronous is not loading in time.
It always seems to point to this code:
var doc = iframe.contentDocument ? iframe.contentDocument : iframe.contentWindow.document, response;
For smaller files the script works great but for larger files the iframe nevers seems to get initialized properly.
This has been driving me crazy. Can someone please HELP.
thanks in advance
You might need to increase the maximum allowed request size on the server as well as the execution timeout of the request using the <httpRuntime> section in your web.config
<system.web>
<httpRuntime
maxRequestLength="size in kbytes"
executionTimeout="seconds"
/>
...
</system.web>
And if you are deploying your application in IIS 7.0+ you might also need to increase the maximum allowed request size using the <requestLimits> node of the <system.webServer> section:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="size in bytes" />
</requestFiltering>
</security>
...
</system.webServer>
I have a strange error I have never run into before.
I secured a controller with:
[Authorize(Roles = "admin")]
public class LoggingController : Controller
When a non-admin user tries to access any protected content, they are redirected to:
http://localhost:50501/Account/Login?ReturnUrl=%2flogging
note: account/login and NOT account/logon
The AccountController.Login action does not exist.
web.config has:
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="2880" />
</authentication>
I can of course implement the Login action and redirect to Logon.
I am just puzzled and would like to know why this happens.
Search your project for login - it has to be specified somewhere. Is there any other web.config value overriding this (maybe looking at a child root and the parent value is being used)
Also is there any redirect that is happening? Are there any defaults set in your machine's web.config?
Is your default url on the project set to be a /login?
Install glimpse route debugger to see which route is being used for this page as well.
EDIT:
A little more research yields a known issue.
Check out this link:
ASP.NET MVC issue with configuration of forms authentication section
Theres a bug in mvc 3 beta - are you running the beta bits?
Also notice the mentioned item in the above url for RTM bits:
<add key="loginUrl" value="~/LogOn" />
Also check out
http://forums.asp.net/p/1616153/4138366.aspx
EDIT 2
Below is a solid comment about a potential source of this from #santiagoIT (upvote his comment please if the specifics help you)
Today I discovered the root of this problem: I had added 'deployable dependency' on 'ASP.NET Web Pages with Razor Syntax'. This adds a reference to: WebMatrix.Data.dll This assembly has a class with a static constructor that does the following: static FormsAuthenticationSettings(){ FormsAuthenticationSettings.LoginUrlKey = "loginUrl"; FormsAuthenticationSettings.DefaultLoginUrl = "~/Account/Login";} That explains!
This worked for me and I'm using MVC 3
<appSettings>
<add key="loginUrl" value="~/Account/LogOn" />
</appSettings>
<system.web>
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" name=".ASPXFORMSAUTH" />
</authentication>
</system.web>
Also I found that adding the followinf part to the web config (only during debugging the config) helped speed up my debugging as had to authenticate for ANY page.
<authorization>
<deny users="?" /> <!-- remove after debugging -->
</authorization>
Just simply remove the WebMatrix dll if they are present in your deployed bin folder.
I fixed it this way
1) Go ot IIS
2) Select your Project
3) Click on "Authentication"
4) Click on "Anonymous Authentication" > Edit > select "Application pool identity" instead of "Specific User".
5) Done.
(This is cross-posted to the ASP.NET forms)
I'm working on the WebGit .NET project, and we are close to a "1.0" release. However, I'm having trouble getting my "Browse" controller (which pulls files out of the repository) to serve-up ".cshtml" files.
I originally had trouble with ".config" and ".cs" files as well, but I fixed that with this in the web.config:
<location path="browse">
<system.webServer>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true">
<clear />
</fileExtensions>
<hiddenSegments>
<clear />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</location>
The routing that should be handling this request (that is successfully routing everything else) is:
routes.MapRoute(
"View Blob",
"browse/{repo}/blob/{object}/{*path}",
new { controller = "Browse", action = "ViewBlob", path = UrlParameter.Optional });
Now, whenever I try to access a URL that ends in ".cshtml", it gives a 404, even though my request should have been handled by the "Browse" controller. The files I'm serving-up do not exist on disk, but are instead pulled from a git repository as blobs. Every other file extension that I have tried works just fine.
How can I fix this behavior?
EDIT: I have tried disabling WebPages like so:
<appSettings>
<add key="webpages:Enabled" value="false" />
</appSettings>
But that appears to have no effect.
As a quick workaround, you can put a temporary browse.cshtml file at your application root and put this inside your web.config,
add key="webpages:Enabled" value="false"
This is a known bug in ASP.NET WebPages, which gets implicitly loaded when you are using MVC 3. I don't think there is a straightforward way of disabling this behavior. The only workaround is to use a different extension (specifically, one that is not listed via WebPageHttpHandler.GetRegisteredExtensions())
This will be fixed in MVC 4, however. Sorry for the inconvenience.
I recently added the Glimpse Debugger package to my project. This added a reference to the Glimpse dll, and modified some Web.Config.
I like my project as much the same as possible on my development and production environment.
So is it save/wise to deploy Glimpse to my production site, or should I create a different project (or create branch from my csproj file) to keep it only locally?
Stuff that I'm worried about include:
Performance
Security breaches
I believe if the cookie for Glimpse is not found it doesn't load or do anything so performance should be negligible. Security wise you can just set a user restriction in the web.config for the location of the glimpse path.
<location path="Glimpse.axd" >
<system.web>
<authorization>
<allow users="Administrator" />
<deny users="*" />
</authorization>
</system.web>
</location>
Or if there is an administrator role you could do it by role instead of user name.
You can also switch it off if you don't want to rely on just the presence of the cookie. This easily achieved through web.config transforms, I haven't tested the markup yet but something like this should work.
<glimpse enabled="false" xdt:Transform="SetAttributes">
</glimpse>
UPDATE: Glimpse has seen some changes recently and (since 1.0 I believe?) the transform would now look as follows. Trying to set the enabled attribute will give a configuration error in the most recent version of Glimpse.
<glimpse defaultRuntimePolicy="Off" xdt:Transform="SetAttributes">
</glimpse>
As the documentation puts it...
Glimpse will never be allowed to do more with a Http response than is
specified in DefaultRuntimePolicy.
It should be noted that the only purpose this transform serves, is if you want to remove the ability to use Glimpse as part of your deployment process. If you want to conditionally disable it based on other criteria such as remote requests or authorization check, these are better done via policies. Glimpse operates off of a series of policies now (all based off of IRuntimePolicy), designed to help determine when glimpse should be allowed to do it's thing. In fact once Glimpse is installed, if you navigate to glimpse.axd, at the bottom of that page, you'll see a list of policies that are currently enabled. Such as the LocalPolicy that prevents it from being accessed by remote requests (configurably, any policy can be ignored via the web.config to allow remote requests) http://getglimpse.com/Help/Configuration. They also have a sample class called GlimpseSecurityPolicy that is included when you install Glimpse using Nuget, which you can use to add a authorization restrictions.
public class GlimpseSecurityPolicy:IRuntimePolicy
{
public RuntimePolicy Execute(IRuntimePolicyContext policyContext)
{
// You can perform a check like the one below to control Glimpse's permissions within your application.
// More information about RuntimePolicies can be found at http://getglimpse.com/Help/Custom-Runtime-Policy
var httpContext = policyContext.GetHttpContext();
if (httpContext.User != null && !httpContext.User.IsInRole("Glimpse")) //Once glimpse is turned on, you have to be a member of this Role to see the Glimpse Panel.
{
return RuntimePolicy.Off;
}
return RuntimePolicy.On;
}
public RuntimeEvent ExecuteOn
{
get { return RuntimeEvent.EndRequest; }
}
}
Now the policies are used to determine when glimpse should run, but they don't prevent the user from being able to bring up the glimpse.axd page. The cookie can still be enabled from what from what I can tell, but the cookie is meaningless if glimpse refuses to run in spite of the cookie being present. That being said It's still advisable to wrap the glimpse.axd page in an authorization check using the location tag in your web.config. Note that this is in addition to the GlimpseSecurityPolicy above.
<location path="glimpse.axd">
<system.web>
<authorization>
<allow roles="Glimpse" />
<deny users="*" />
</authorization>
</system.web>
</location>
Yarx is right on pretty much all fronts.
From a security perspective you could lock down the path using the method described. Only thing is, there are more URL end points that glimpse uses, so the rule would need to be something like *Glimpse/* (where * says that anything can come before it and anything can come after it). Once this is in place, glimpse should be pretty locked down.
Also, if in the config, you used the transform that Yarx provided, glimpse will never load, even if you have the cookie turned on.
Starting with Glimpse 1.7 there is a more generic way to secure ~/glimpse.axd with the additional benefit that you use the same policy for all. You simply need to make sure that your custom policy is called for resources too:
public RuntimeEvent ExecuteOn
{
// The bit flag that signals to Glimpse that it should run on either event
get { return RuntimeEvent.Endrequest | RuntimeEvent.ExecuteResource; }
}
Notice the | RuntimeEvent.ExecuteResource. See bottom of: Securing Glimpse.axd the way forward.