I was able to get the DotNetOpenAuth set up in my MVC3 project. (Took a long time, but finally was able to get all the missing pieces.)
However, now I'm getting a 414 error from Google that the request URL is too long. I found that google is saying in those cases the request should be a post and the issue would be gone. I was wondering if there was a way to construct post instead of a get when the popup windows are being pre-loaded?
I'm using nerddinner as my stepping stone, and have used the code in the AuthController code to get the url's preloaded. http://nerddinner.codeplex.com/SourceControl/changeset/view/70027#952619
Is it possible to do a post in those popups? Or how did people get around the 414 error for Google?
DotNetOpenAuth already 'upgrades' long URLs from GET to POST, and does so at the 2048 character length threshold. There have occasionally been reports that this threshold is too high, and it is adjustable by web.config file setting. However, I don't think that adjusts the AJAX .js file on the client (yet).
If you will please file a ticket describing this problem, we can get a maintenance release of DotNetOpenAuth out that resolves this issue.
FYI the .js file is found in the DotNetOpenAuth project source code and is called OpenIdRelyingPartyControlBase.js. But since it compiles as a resource into the dotnetopenauth.dll and downloads to the web browser directly from there, it makes it inconvenient for you to fix with an adjusted threshold.
Related
The Problem
I have a website running in IIS. If I rename or delete one of the layout page .cshtml files under /Views/ the site immediately begins throwing following yellow screen error as expected
The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".
What surprises me is that if I recreate or rename the file so it is exactly like it was before, the yellow screen persists. Why is this particular 500 error sticky?
I currently think that this has something to do with IIS and is specifically related to error handling. The site immediately detects that the layout page file is missing. It does not immediately realize when the file is back in place.
Thanks!
Some interesting clues
This happens on all of my sites I've tried this on so far. It isn't related to a specific site
I tried this on two websites at the same time. On one site I repeatedly and consistently refreshed the page hoping for a success. On the other, I left it alone for several minutes before checking again. The site I leave alone will resolve its problems and find the layout page on disk again. The site I continually make requests to appears to display the error indefinitely.
What I've tried
I have reproduced the problem on Umbraco websites using Umbraco's default routing as well as regular MVC pages using custom routing. The problem is the same for both.
I don't have output caching configured in IIS
When I am reproducing the yellow screen error, I am able to reproduce the error in multiple browsers, so I don't believe it is related to browser caching
I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
I am able to reproduce the problem on websites where there is no custom code for caching. No CDN. No load balancer.
Versions
IIS: I have reproduced the problem on Windows Server 2012R2 running IIS 8 and Windows 11 running IIS 10
CMS: All of the websites I have tested on so far are Umbraco 7 sites. However, I have reproduced the problem on pages that are routed using Umbraco's out of the box routing as well as pages that are just set up using MVC and aren't leveraging Umbraco.
It appears to be part of the behavior of FcnMode="Single". See https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-4.8. It isn't an issue with caching. It is a problem with the way that the site's file change notifications (FCN) are configured.
The sticky 500 behavior on renaming files happens when I use FcnMode="Single" but not when I use FcnMode="Default".
FcnMode="Single" will result in only a single object to monitor file changes. This single object is responsible for monitoring changes to files in the main directory and sub directories.
FcnMode="Default" will result in a separate object to monitor file changes for each directory.
Umbraco sites, by default, use FcnMode="Single". This makes sense because Umbraco sites cache under very deeply nested directories in /App_Data/. This can result in so many of these monitors that it can affect the performance of the site. There is a great explanation of FcnMode and why it matters for Umbraco here: https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/
Unfortunately, it appears that the single file monitor can miss renames of files in some cases.
I've run into a bug where my website will not allow a user to click a valid hyperlink from a microsoft word document (2010, 2013 tested) and correctly go to the website.
The website is using MVC architectural patterns, so any action such as index, help, etc do not work.
Has anyone ran into this issue, if so, how was it resolved? I can't seem to find any other issues like this being listed.
It would be helpful to see the exact error message - was it "invalid browser error"? Errors like that are usually related to an issue with Internet Explorer trying and failing to handle the URL, even though it may not be your default browser.
See here and here.
I have an MVC app and when I first open it up (in a new browser, ie new session) I am getting some strange characters added to my url after the site name part. It always starts with (X(1)S( and the characters change each time.
(X(1)S(y2bk1ahqgpv42uwh0mcpsdxw))
Does anyone have any ideas what is causing this? Is this some cookie setting in IIS or web.config?
It's causing some problems, one of which is the modelstate is invalid due to an error with no error messages.
Deploying to IIS.
Get the following response in Fiddler:
HTTP/1.1 302 Found
Location: /mysite/(X(1)S(hvuk0jbaokfmxtlvm54d4cvc))/
<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="/mysite/(X(1)S(hvuk0jbaokfmxtlvm54d4cvc))
Not sure what other info I can give that could be relevant, I'm hoping someone has seen these characters before and know what they're about.
Thanks
So this was bothering me all day then as soon as I put it on SO I find the reason.
The original URL I was requesting had the following querystring parameter.
&AspxAutoDetectCookieSupport=1
Remove this and although it gets appended automatically the other characters don't and everything works.
The problem was we had copied the URL in the past with this parameter as it had been automatically added. However if you request a url with this parameter in it, you get the above issue.
I think this is the solution, maybe others know some more information.
In my ASP.NET MVC 4 project, I am using the Microsoft.Web.Helpers (from the NuGet package) and my code is a very basic implementation of ReCaptcha. In my view I have:
#ReCaptcha.GetHtml(theme: "clean")
In my controller I have:
Microsoft.Web.Helpers.ReCaptcha.Validate();
The complexity comes with the SSL implementation we are using.
I have added the appropriate settings to my web.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://***proxy script settings**"
autoDetect="False"
usesystemdefault="False"
bypassonlocal="True" />
</defaultProxy>
</system.net>
There seems like there is nothing further I can do in terms of config, but I am getting the error message
The remote server returned an error: (404) Not Found
when I hit the recaptcha validate method on the form post method in my controller.
Ive found a number of other answers on here but they all seem to suggest that you change the url, or upgrade. As Im using a NuGet package I would have thought I was using the latest version. Any ideas or links with more information greatly appreciated. Ive already done quite a bit of looking both on this site and google
edit:
I have found that earlier versions of firefox have trouble actually rendering the recapture box given our network conditions, but the latest one is fine. As the validation is done on the controller though, I suppose there is no issue here.
After much pulling of hair and general confusion, I discovered that the problem was that the POST (but not the GET) to the google API was being blocked by our corporate firewall. I had previously discounted this, because I could navigate to the service that recaptcha uses (http://www.google.com/recaptcha/api/verify).
I found this by constructing an HTML page of the requisite parts for the post and submitting it in a browser. The corporate "This page is blocked" appeared - however in code the error that is returned is a 404. The error is somewhat misleading, but this is bizarre behavior from our infrastructure department.
I have a strange issue with an Asp.NET MVC application.
Using Asp.NET MVC 3 Preview 1 on IIS 7.5 - Integrated
After building the application everything runs fine. Then after some random amount of time (or sometimes after updating a view or js file) the application dies.
Meaning, requesting the root page, I get the 403 error and requesting any other page I get a 404 error.
After a rebuild everything works fine again for a little while until it dies again.
I am seeing this on two different development machines. Also, I have another application which is very similar (MVC 3, IIS etc) on both dev machines and this one runs without problem. I have inspected the config files in detail and cannot see anything of notable difference.
Does anyone know what could cause an application to die or where to look for further information? (I can still access elmah.axd though no information is there).
There's not much to go on here, but the 403 and 404 are clues that at least ASP.NET routing is not working; 403 is coming back because the web server thinks you want to do a directory browse, 404 because your request doesn't have a valid corresponding resource.
Since you are using the new version of MVC, I would suspect the issue may lye there. When you get the error condition, can you browse to a regular .aspx page? Does it execute server side code correctly?
You have the site hosted in IIS 7.5, not just the built in Visual Studio web server, right? Is it possible to turn on monitoring/event logging to see if IIS is taking a hit?
I apologize for not having any actual answer, sounds like you have a tough issue to debug.
Good Luck!