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.
Related
I'm trying to help our System Admins here, so please don't beat me up for my lack of knowledge. We can run the application locally and we can build and deploy to our Test Server and the application reports work as expected. But when we deploy to our Production Server, many of the Get and Post Ajax calls are getting 500 errors. Essentially, all reports run everywhere EXCEPT on the Production Server.
This is an ASP .NET MVC application with the views being Razor HTML and JavaScript. The model, controllers, and services are all in C#. IIS 8.5 web server and SQL Server for the database.
I've Googled and tried everything I could find. More detailed errors show us the service call that fails along with the parameters and all looks good. Again the application reports run fine in all environments other than the Production Server. Does anyone have any idea why this is happening and what we should be looking at to resolve the issue?
Thank you in advance.
Just turn off custom errors in the web.config file
<system.web>
<customErrors mode="Off">
</system.web>
and then open up the development tools in a browser during one of the GET requests and replay the GET yourself. Should get the exact error message back.
It took us all day to figure out that one of the parameter tables did not have the appropriate permissions. Which would explain why some reports ran while others consistently returned a 500 error.
I am trying to hide my server signature Microsoft IIS:7 from my websites. I searched too much, lots of links, code suggestions and articles, but none of them works for my Asp.net MVC project. I found a suggestion here Removing/Hiding/Disabling excessive HTTP response headers in Azure/IIS7 without UrlScan
that maybe a Nuget package named NWebsec do it. I added this package to the project and and then it added some new codes to my web.config. The problem is that the project works fine in offline mode, but when I upload the published files in host server, it has error on line 24 which it is this
<authentication mode="None" />
I think it may have some conflict with something named owin which it added. Appreciate any help for this question or any other way suggested to remove my host name from my website.
My site is in Rails 4.1.7 and is hosted in Ninefold.
I want to verify and add Google Analytics to it.
I tried uploading html file in public folder, no go.
I tried creating controller and route, didn't work.
I tried a couple of solutions that were supposed to do a workaround in turbolinks and added the analytics script to the footer. Didn't work
Any ideas?
I must add that in the first two solutions, the html / action were accessible through the browser call but not through external links (when you try to verify, it gives you a link in webmasters tools), which has led me to believe it's a csrf situation, where rails blocks incoming connections from other websites.
UPDATE: I have this solution live, analytics shows me some data but site verification still does not work.
UPDATE 2: Ok, i solved it. The problem was that i had stated the domain as domain.com in Ninefold and forgot about it, and then i was trying to verify www.domain.com in Google. Solved by adding the extra domain and verifying both of them.
I have a preexisting MVC app that I added Web API and Web API Self Documentation using Nuget. While the Web API controllers function fine (return valid responses to HTTP requests) the Help controller is not finding any Web API methods to document.
In the Help controller Index action "Configuration.Services.GetApiExplorer().ApiDescriptions" is returning with 0 results.
I even went as far as copying the entire "HelpPage" area from another functioning web app.
What populated ApiDescriptions and are there any config settings I need to set to expose my api to documentations?
Things I have tried:
Reinstalling nuget packages
Copying over HelpPage area from working project
Copying over routes from working project
Comparing references from working project to broken project
Comparing Global.asax.cs from working project to broken project
Comparing web.config's from working project to broken project
It turns out my Glimpse MVC 4 installation was interfering. This is a known issue with Glimpse and Web API Help Pages. Uninstalling Glimpse fixes the problem.
The link provided by William also provides the following work-around in this comment which worked for me:
For now, you can use a simple workaround by ignoring the RoutesInspector. Just add this to your web.config:
<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
<inspectors>
<ignoredTypes>
<add type="Glimpse.AspNet.Inspector.RoutesInspector, Glimpse.AspNet"/>
</ignoredTypes>
</inspectors>
</glimpse>
I am trying to get a demo site for a client setup. This is the 1st application my company is doing in MVC.NET, so I get to experience all the new things to find out (and all the headaches it'll cause).
Anyway, the site works fine locally (localhost) and on the server inside our domain. External users not on the domain however, only get 404 errors. I've tried several different settings/ config options I've found on this site, but nothing is working. I don't know if it's a web.config issue or an IIS issue, or even simply a permissions issue (though it has all the same permissions as the other sites we run with Web Forms).
IIS: v7 in intergrated mode.
Windows Server Web
Well, because you received a 404, the server is being reached okay which is a good sign. (Dealing with firewall issues at a company is always a lot of fun.)
A common problem for something like this is the use of virtual directories to host the website. For example, if the address to your site is http://example.com/MySite/, in MVC that would translate to: /MySite/View/Index.aspx. HOWEVER...if you are using virtual folders, /MySite/ may instead point to another spot on the server (e.g. C:\WebSites\MySite). If you are indeed using virtual paths, make sure you have your files stored at the correct path.
There is a troubleshooting tutorial here: http://support.microsoft.com/kb/248033
thanks for the answers everyone. Turns out it was something with our DNS routing setup with the sub-domains. It was getting rerouted to a place that didn't exist. Our IT guy finally got around to fixing it (ugh!)