I am new to Nancy and am playing with the tracing and other diagnostics details. The documentation at https://github.com/NancyFx/Nancy/wiki/Diagnostics states that I should be able to hit the diagnostics dashboard by using the address http:///_nancy. My app is running at http://127.0.0.1:55368/ but when I enter http://127.0.0.1:55368/_nancy, I am getting a 404 status code. Is there something else I need to do to enable the diagnostics page in nancyfx version 0.23.2? My app is only a simple api and does not use views.
Thanks
UPDATE
The documentation on the page listed above states:
Without the password you will be presented with a page telling you that the dashboard needs to be configured in order for you to use it, along with instructions on how to perform the configuration.
However, I received a 404 instead. Once I configured a password in the bootstrapper as per the docs, the login screen showed up.
If you are running your app in Release mode, you'll just get a 404 straight away. See this issue: https://github.com/NancyFx/Nancy/issues/625
and commit: https://github.com/NancyFx/Nancy/commit/002bb9573c5ccd2437233f5bd518762c0ee77b35
Updates so that StatisConfiguration.IsRunningDebug is public. The
DiagnosticsHook will not check that flag before returning the
diagnostics help view. If true then it will return NotFound instead.
Related
I am trying to execute Test Suite to certify, but I receive an error when executing the action. I can't find anything in the Google Cloud log. Everything works fine using Google Assistant on my phone and Nest.
enter image description here
A 503 error code means that the requested service is temporarily unavailable at the moment. You can wait for some time before trying again & make sure that your Smart Home Actions are linked with an account & testing is enabled for your actions. For instructions on how to set up your account for testing, check this link.
If the issue still persists, open up a ticket on our Public Issue Tracker.
I am running a website on Google App Engine. From time to time I get out-of-control bots or perhaps brute force hacking attempts that I see in my logs. Recently I've had a bot (I presume) trying to access administrator/index.php several times a second. That file doesn't exist on my site. If I try to access it, I get the standard 404 and this in my logs:
But for the bot I am seeing HTTP 301 in the logs and I'm wondering why. Does Google interpret the requests as a denial of service or other attack and automatically intervene? I haven't seen documentation stating as much, but I'm not sure why else I would be seeing the 301 instead of 404 for the same URL:
Does anyone have an explanation for this?
The log entires shown on the screenshots can be clicked & expanded to view additional information. As mentioned in the comment above two things could be checked there for further analysis of what's going on:
check the hostname of where the request came to & see if it's not the expected behaviour for that hostname.
if the json object is shown, navigate to protoPayload -> line -> [0] -> logMessage where something like redirecting "http://example.com/" to "https://www.example.com/" should be shown which could also clear things up a bit.
I am currently configuring ELMAH 1.2 to log errors within our Ektron 9.1 application, however it will not log any 404 errors. ELMAH is currently functional as it is logging other errors (including unhandled exceptions), just not 404 errors. I am not running an MVC environment / 3-Tier Ektron Architecture, we are still using the traditional ASP.NET / Ektron Web Forms solution.
I know ELMAH logs these errors by default, so I'm wondering if I'm missing something with regards to how ELMAH is interacting with Ektron. There's not much information out there on the topic, and the one article I found is dated from 2010, so the information is severely outdated.
It's different for URLs that end in .aspx and other ones. If a user goes to your site and accesses /ThisFileisnothere.html The static file handler would handle that. Ektron replaces the static file handler with the EkDavHttpHandlerFactory. Ektron's handler doesn't throw an exception. It doesn't trigger an Application.Error Event. It just sets the statusCode to 404. If you wanted to do something custom like log an error to ELMAH, you could hook the Application.PostRequestHandlerExecute and check the Response.StatusCode
If a user tries to go to /ThisPageisntHere.ASPX then a different handler will handle that URL and will trigger the Application.Error event that ELMAH should catch.
I can't access the Datastore Admin tab due to a "This webpage has a redirect loop" error and I can't figure out what I'm doing wrong or have set up wrong.
I have Datastore Admin Enabled in my web console.
I've added (although I don't know if this is even necessary):
builtins:
- datastore_admin: on
I've cleared cookies, etc.
Authentication Options is set to Google Accounts API
Has anyone else seen this or know how to fix it?
The issue is being discussed here and I am going to answer it.
http://code.google.com/p/googleappengine/issues/detail?id=4233
First a question. Which browser is this on?
I've had this problem on chrome and it's related to Chrome blocking third-party cookies, over-all a nice thing for it to do. You can add an exception to your third-party cookie settings to make fix the problem.
You need to go to the Chrome settings page. You may need to expand an option called Show advanced settings...
Then look for:
Privacy / Content settings...
Cookies / Manage exceptions...
Then add an exception at the bottom of this list. The exception should look like this:
https://ah-builtin-python-bundle-dot-latest-dot-[YOUR_APP_ID].appspot.com/_ah/datastore_admin/*
I get this warning often in my Google App Engine for Java warning console. It's strange because the URL that it claims isnt handled, is the url generated by GWT (im using GWT client-side).
Heres an example: /myAppName/62865E45F313D707543A6F093D199127.cache.html
They only happen occasionally, but its enough to make a single visit useless.
I'm not 100% sure, but it could have to do with browser cacheing (though the *.ClientMod.nocache.js is specifically designed to prevent this). Does clearing your browser's cache or visiting the page in incognito mode help?