Disabling and enabling miniprofiler when working with Umbraco 7 - c#

This is a two part question, which circles around the same problematcis.
Without setting anything up in Global.Asax, and just inserting this line in my .cshtml file for my basic layout, and running my site in debug mode, the MiniProfiler is automatically displayed in my frontend.
#MiniProfiler.RenderIncludes()
Trying to shut down the MiniProfiler doesn't seem to work. I have tried something as obvious as the following code, but the MiniProfiler is still run, and is still represented in my frontend, when running my site locally:
protected void Application_BeginRequest()
{
MiniProfiler.Stop();
if (!Request.IsLocal)
{
MiniProfiler.Start();
}
}
Furthermore In Umbraco.Core's WebProfiler I found the following code:
if (GlobalSettings.DebugMode == false)
return false;
In my case, i would like to be able to let the Profiler run on my clients site, but that's not possible as DebugMode is always false when I publish my code to my clients site.
Ideally I would like to do something like:
protected void Application_BeginRequest()
{
MiniProfiler.Stop();
if (Request.IsLocal || Request.UserHostAddress == "My/developers IP")
{
MiniProfiler.Start();
}
}
How can I programmatically stop the MiniProfiler to set up cases where I don't want it to run when in DebugMode? And how can I make the MiniProfiler available for developers on my customers live sites?

Related

Control output of MiniProfiler for .NET in web app

I followed the setup instructions here https://miniprofiler.com/dotnet/AspDotNetCore and got Mini Profiler working with my ASP.NET core web app. I pushed the code up to my staging site and now see the output on every request.
Previously local only access was documented here https://miniprofiler.com/
using StackExchange.Profiling;
...
protected void Application_BeginRequest()
{
if (Request.IsLocal)
{
MiniProfiler.Start();
}
}
How can I restrict miniprofiler to only show for local requests in ASP.NET core
From the documentation:
services.AddMiniProfiler(options =>
{
// (Optional) To control authorization, you can use the Func<HttpRequest, bool> options:
// (default is everyone can access profilers)
options.ResultsAuthorize = request => CanAccessMiniProfiler(request);
options.ResultsListAuthorize = request => CanAccessMiniProfiler(request);
}
You can implement it any way you like:
private bool CanAccessMiniProfiler(HttpRequest request)
{
// Add your logic here, e.g. check for local requests and certain roles
}

Hangfire Authorize runs multiple times

This code runs every seconds for me:
public class CustomAuthorizationFilter : IDashboardAuthorizationFilter {
public bool Authorize(DashboardContext context)
{
if (HttpContext.Current.User.IsInRole("Admin"))
{
return true;
}
return false;
}
}
Could you help me why? (I managed to null check HttpContext.Current.User, but this code runs every second)
When you have the dashboard open many Ajax request are made to keep the UI up to date. These are likely the request you are seeing. You can inspect the context in the debugger to see the specific route being called. Also the F12 developer tools in chrome (network tab) will give you some insight as well.

How to display errors with ASP.NET Core

I have a fairly simple website that I am playing with using ASP.NET Core. I am running the application from the command line and the website is returning static files but I keep getting 500 errors when I attempt to make a request that should get handled by MVC. How do I see what the error is? Whether the error is displayed to the browser or logged to the console doesn't matter I just want a way to see what the error is.
Add the error page middleware as shown here:
app.UseDeveloperExceptionPage();
Update for beta8:
In beta8 Microsoft changed the name to UseDeveloperExceptionPage. So if you want to use the ErrorPage, call:
app.UseDeveloperExceptionPage();
Here is the link to the related Github issue.
The ErrorPageOptions are the same as in beta6/7.
You can use
app.UseErrorPage(ErrorPageOptions.ShowAll)
until beta5 of Asp.Net Mvc.
As of beta6, ErrorPageOptions.ShowAll has been removed. You can now use the version without parameters
app.UseErrorPage();
or create an ErrorPageOptions object and specify how many lines around the error you want to display by setting SourceCodeLineCount.
app.UseErrorPage(new ErrorPageOptions() {SourceCodeLineCount = 100});
Additional Information
They removed multiple properties of ErrorPageOptions in this commit.
Before:
public class ErrorPageOptions
{
private bool _defaultVisibility;
private bool? _showExceptionDetails;
private bool? _showSourceCode;
private bool? _showQuery;
private bool? _showCookies;
private bool? _showHeaders;
private bool? _showEnvironment;
...
}
After:
public class ErrorPageOptions
{
public int SourceCodeLineCount { get; set; }
public IFileProvider FileProvider { get; set; }
...
}
So now you can only set how many lines of source code are printed.
If you don't care that your error details would be exposed to the world, you can enable the error details, right in the browser without any code changes. (This was only tested in IIS 8.5):
In IIS Manager, in the left Connections section, left-click select your Site.
In the right side Feature View open Error Pages.
On the far right Actions section, click on Edit Feature Settings
In the Error Responses, select the 2nd, Detailed errors, option then Ok (or if you are worried about exposing stuff to the world, start with the 3rd option, if you can open a local browser... ie, localhost:...)
This should be enough for you to be able to see the exact error... Important: If you had to use the middle Detailed errors option, be sure to turn it off once you debug the problem. This can give a hacker all he needs to break into your server.
If it is not important to expose the detail of the error to the world, then you can activate detailed error page in web.config.
Just add <customErrors mode="Off"/> in the <configuration> / <system.web> of your web.config file located in root folder of your web site.
For more detailed explanation:
How to Use Web.Config customErrors for ASP.NET
This has the advantage that you don't have to redeploy your site

ASP.NET HttpContext Items vanish on server

We are currently seeing an issue with the use of HttpContext.Current.Items where the local environments of the developers show no issues (all works as expected) in the server environment we are suddenly loosing items placed inside (getting a NullReferenceException).
I sketched some code and use below:
Global.asax we initialise the factory at BeginRequest:
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext.Current.Items["Key"] = new Factory();
}
Inside the BaseControl we have a property to retrieve the factory easily:
public Factory Factory
{
get { return HttpContext.Current.Items["Key"] as Factory; }
}
In the UserControl we use it through the base property:
protected void Page_Load(object sender, EventArgs e)
{
Product p = Factory.CreateProduct();
}
Environment information:
Local DEVs are running on Windows 7 and 8 using IIS 7.5 and 8 and Sitecore 6.6
The server is running Windows Server 2008 R2 using IIS 7.5 and Sitecore 6.6
For all local DEVs (we're working on this project with 6 people) there's no issue with the code described above. However once we deploy the code to the test server the locations that use the Factory break (ea the HttpContext.Current.Items is empty)
I can imagine only 1 scenario when it behaves like you described: in the Global.asax file the Inherits property on the test server points to the Sitecore.Web.Application directly omitting your code execution.
Could you double check if the Global.asax file starts with
<%#Application Language='C#' Inherits="My.Assembly.Namespace.Global" %>
This could happen if the Global.asax was changed in your dev enironment but hasn't been deployed to the test environment.
If it's not an issue, try to check if the Application_BeginRequest is executed on the test server. It would give you an answer whether the Factory is never added to HttpContext.Current.Items or whether it's removed from the Items during the request handling.
I noticed you use the same name for your property as it's type:
public Factory Factory {}
Maybe this initiates some unexpected behavior?

PhluffyFotos does not work on Azure SDK 1.3

I have tried PhluffyFotos example on Azure SDK 1.2 and it works perfect. Today I have installed on another (clen) computer Azure SDK 1.3 and I have also want to try PhluffyFotos on it but it does not work. I have problem with this part:
if (!Roles.GetAllRoles().Contains("Administrator"))
{
Roles.CreateRole("Administrator");
}
It seems it somehow does not load the custom RoleProvider (TableStorageRoleProvider). Do you have any idea what it could be?
I get the following error: "The Role Manager feature has not been enabled.", because of the following exception "'System.Web.Security.Roles.ApplicationName' threw an exception of type 'System.Configuration.Provider.ProviderException'".
Can someone test this example and see what is the problem? http://phluffyfotos.codeplex.com/
Firsty I have the "SetConfigurationSettingPublisher" problem with this example, but I have successfully resole it.
EDIT:
I have look deeper into it and I am sure there are a problem with Role provider. Somehow the Roles class do not read config file. Have anyone any idea why?
I have the exact same problem with my own project. I verified with Fusion logs that the assembly which contains the custom providers dont even load. so it seems the problem is somehow related to the web.config settings being ignored.
To run PhluffyFotos example on Azure SKD 1.3 you have to the following:
Change reference Microsoft.WindowsAzure.StorageClient from 1.0 to 1.1
Move "GetConfigurationSettingValue" to the Global.asax "Application_Start" event.
Move Role related initialization to the Global.asax "Application_BeginRequest" event, but you have to ensure that it executes only once. Example:
private static object gate = new object();
private static bool initialized = false;
protected void Application_BeginRequest()
{
if (initialized)
{
return;
}
lock (gate)
{
if (!initialized)
{
// We need to check if this is the first launch of the app and pre-create
// the admin role and the first user to be admin (still needs to register).
if (!Roles.GetAllRoles().Contains("Administrator"))
{
Roles.CreateRole("Administrator");
}
if (!Roles.GetUsersInRole("Administrator").Any())
{
Roles.AddUserToRole(RoleEnvironment.GetConfigurationSettingValue("DefaultAdminRoleUser"), "Administrator");
}
initialized = true;
}
}
}
I posted a version of the code with the fixes suggested by Peter to rapidshare here:
http://rapidshare.com/files/434649379/PhluffyFotos.zip
For those who don't want to fuss around fixing the dependencies etc.
Cheers,
Daniel

Categories