I'm trying to get service requests to show up in Fiddler. I found that I can add the following to my service projects to accomplish this:
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy autoDetect="False" bypassonlocal="False" proxyaddress="http://127.0.0.1:8888" usesystemdefault="False" />
</defaultProxy>
</system.net>
That worked like a charm for anything originating from the server, but when there is an error processing a request coming from the Android Emulator, it will still not show up. So I would like to do the equivalent in the Xamarin Forms project (except, of course, I would set the proxyaddress to 10.0.2.2:8888 for the Android emulator). I am not as experienced with Xamarin though and there is no web.config to add this to.
I'm about to just try doing it programmatically which is okay, but is there a way to do it through configuration, perhaps in the App.xaml file?
If there are better ways to do this, I am also open to other suggestions that accomplish the same goal of being able to inspect the web requests/responses. I'm a bit new to this so this is the only way I know to try at the moment.
Related
Im building some Blazor wasm project
and to access OIDC i had to make my dev iis expres to run under https:/xxx.localhost
and OIDC is veryfying this callback url so it mus be like that
so i had to add to my hosts xxx.localhost 127.0.0.1
and then edit
applicationhost.config and add
<binding protocol="https" bindingInformation="*:443:xxx.localhost" />
then
netsh http add sslcert ipport=0.0.0.0:443 certhash=certhash.. appid={appid...}
and it is wotking - now i can run it on xxx.localhost but i canot debug.
i see breakpoints not hit like like this
what shoud i do to be able to debug like this also? did i do something wrong ? please advise.
best regards !
for future readers
solution was pretty simple
issue was with my corp network and PROXY
for xx.localhost it was going thru proxy not directly !!!
shame on me
regrds.
I am getting the following error when I try to load nget:
Unable to load the service index for source
https://api.nuget.org/v3/index.json. The ServicePointManager does
not support proxies with the https scheme.
Also, in Linqpad, I am getting a similar error:
ServicePointManager does not support proxies with the https scheme
Does anyone have any solutions for this? I found this post, but that solution, clearing the temp folders, did not fix my problem. Please help! Thanks!
The ServicePointManager does not support proxies with the https scheme.
Since you have proxy configured in the web.config, you may need to pay attention to the syntax of proxy.
You will also get this error if you set something like this in your web.config file: proxyAddress="127.0.0.1:8888"
You need list the scheme like this: proxyAddress="http://127.0.0.1:8888" (Add http://). The only scheme that is recognized by this class is http.
Besides, since you have proxy configured in you machine, NuGet will fail to access to the server. You should add proxy settings into Nuget.Config file, goto %AppData%\NuGet\NuGet.config, add below settings:
<config>
<add key="HTTP_PROXY" value="http://127.0.0.1:8888" />
</config>
You can refer to the NuGet Proxy Settings for more detailed info.
Found the problem! I basically just needed to remove the proxy setting from nuget and it looks like the command line was the best place for it. Thanks to #Leo-MSFT for the helpful suggestions.
Update: [8/8/2017] The problem has reemerged but this time, my fix won't save me since its still applied. I've checked all 3 spots for the nuget proxy settings and its still not working. I have no idea what's wrong now. Grrrr!!!!
Update: [8/8/2017, part deux] Found it! I had fiddler set in the machine.config as well, so make sure to check that if you are prone to forgetfulness like I am.
<system.net>
<!-- <defaultProxy
enabled = "true"
useDefaultCredentials = "true">
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false" />
</defaultProxy>-->
</system.net>
Fiddler was the culprit in my case too. I had to comment proxy settings from machine.config
residing in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config.
<system.net>
<!-- <defaultProxy enabled="true" useDefaultCredentials="true">
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false"/>
</defaultProxy> -->
</system.net>
I have googled for the past 3 hours and found nothing on what to do with respect to the windows azure problem:
You do not have permission to view this directory or page.
I did a git master push to azure and the deployment was successful. I also turned on the failed request tracing but nothing shows up but the above statement.
Any ideas on how to troubleshoot this?
I just tested that if you don't deploy your main node.js file as server.js you will get this error because the web.config is specifically looking for server.js as below:
<handlers>
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>
To further troubleshot this issue you can access the website over FTP as described here.
AvkashChauhan's answer did lead me in the right direction but I also had to add proper rewriting rules. Here is my complete web.config
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation batch="false" />
</system.web>
<system.webServer>
<handlers>
<add name="iisnode" path="server.js" verb="*" modules="iisnode" />
</handlers>
<rewrite>
<rules>
<rule name="myapp">
<match url="/*" />
<action type="Rewrite" url="server.js" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
I hit this error too. I am using MVC and the reason for the error was that on my layout page I had a call to an action that isn't accessible to anonymous users:
#Html.Action("GetMenu", "Users")
For information, I register a AuthorizeAttribute() global filter in Application_Start and my Login action is decorated with AllowAnonymous:
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
My website did work previously on IIS7, but Azure is less forgiving. I fixed the problem by adding a check like this:
#if (User.Identity.IsAuthenticated)
{
#Html.Action("GetMenu", "Users")
}
The azure tools have changed a lot since this question.
I recommend people using the azure-cli. But funny enough I actually don't use it after I have used it once to create a site.
What I use now is just the ability to push (git) directly to a remote that is named azure, and the cli is setting that up for you.
But if you don't want to install the cli you can essentially just add the remote repo (your site) manually, like this:
git remote add azure https://<site-or-appservice-name>.scm.azurewebsites.net/<site-or-appservice-name>.git
As you would with every other git remote.
Not specific to node.js but updating in case it helps others facing this issue for a regular web application. This can also happen if the index.html file is not present or is not found because it is in a sub-directory
I just came across this issue and in my case it was the ipSecurity configuration that was causing the issue. Just hd to go and change the allowUnlisted to true.
<security>
<ipSecurity allowUnlisted="false">
</security>
Simple configuration, in the azure portal go to your
web app ->
All settings ->
application settings,
under default documents add the specific name of your document which you want to view, wait for it to update, then refresh your azure link.
I had the same error message after a git push from a local repository.
Solved it by opening the Azure dashboard:
Web app / App deployment / deployment source
and selecting local git repository as deployment source
You need to move your server.js file to your root app folder.
Lots of answers, but I didn't see one that addressed the "how do I debug this?" question, which wasn't obvious to me as someone who is new to Azure and hadn't yet used Kudu diagnostics.
To see the debugging info you're looking for, just navigate to
mywebsite.scm.azurewebsites.net
when you encounter the "You do not have permission to view this directory or page." error on your own
mywebsite.azurewebsites.net
page. This will get you to the Kudu console and give you easy access to everything currently in your logs.
See also the many answers to the closed-but-popular How to debug "You do not have permission to view this directory or page"? question.
I rectified my HttpWebRequest initial calls being slow by using the suggestion mentioned at
Why is this WebRequest code slow?
One of the suggestions mentioned to set the Proxy to null and things will speed up.
I have done this and it worked.
However Im concerned about the impact of this when I deploy this at some client sites....
It may be at some client sites that have configured their domain to go through a proxy to reach the server in which I am making my HttpWebRequest to.
Will setting Proxy properly to null impinge upon this?
Thanks
I wondered the same thing too. I was not able to find any answer to this question, though.
However, I did find that you can accomplish the same effect as hard coding httprequest.Proxy = null by adding a setting to the application config file:
<system.net>
<defaultProxy>
<proxy bypassonlocal="true" usesystemdefault="false" />
</defaultProxy>
</system.net>
My thinking is that if I ever find myself at a customer site where I need to change the automatic proxy detection I can remove the settings from the config file.
I found this fix at the following site:
http://weblog.west-wind.com/posts/2005/Dec/14/Slow-Http-client-calls-from-ASPNET-20-Make-sure-you-check-your-Proxy-Settings
I have cornered this error down to a redirect action call by DotNetOpenAuth(http://www.dotnetopenauth.net/)
Basically I have implemented the example here
http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/
In my application while running locally I hit this line
return request.RedirectingResponse.AsActionResult();
At this point it completes this action and then the azure dev fabric load balancer crashes.
Here is where it gets strange. If I debug line by line into the redirect action it will not crash.
Has anyone seen anything like this that can give me some direction on a fix?
#dthorpe points out that I should tell you all I have tested this by deploying to the production environment and this does seem to work.
We had same problem. There is no fix I currently know of and application still works fine, while deployed in the cloud.
Yet for the local testing purposes I merely introduced switch (it could be compile-time ifdef DEBUG or configuration switch). Whenever there is attempt to authenticate via the OpenID in local dev fabric, we immediately assume the identity is valid and authenticated by the DotNetOpenAuth. This worked for us and allowed to move the development forward.
I have a fix. It's a slight hack, but it does work and you don't have to fake anything.
Change this:
return request.RedirectingResponse.AsActionResult();
to this:
string location = request.RedirectingResponse.Headers["Location"];
return Redirect(location);
This gets around the issue and allows authentication to proceed. I'll allow someone brighter than myself to give a detailed explanation as to why this is the case.
Hope this helps!
If anyone's looking for a quick fix for this, one option is to turn off Azure diagnostics, if you happen to not be using it. This is added to the web.config when you create your project, just comment out the "add" element as shown and you're done.
<system.diagnostics>
<trace>
<listeners>
<!--<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>-->
</listeners>
</trace>
Of course this turns off diagnostics so only do it if you're not using diagnostics!