When you attempt to deploy an ASP.NET Core project to App Service on Linux, you may run into an error during the build process – Object reference not set to an instance of an object. When you try to deploy the project to App Service on Windows, everything works, so where is the issue?
I am sure you have heard of App Service’s feature called Local Cache, which allows to cache all the files locally on the instance instead of pulling them from the shared storage which can lower the application’s load times – especially when using just-in-time compiled code like PHP. This great feature however, is only available currently on App Service on Windows, and in this article, we are going to explore the options of having something similar on App Service on Linux powered by Docker.
During Build 2017, Microsoft announced bunch of new features for App Service on Linux. One of those features announced was support for SSH support directly into the web worker instance. Based on my previous article about building a custom image for ASL, I have updated the HHVM image both on GitHub and Docker hub to have SSH support as well.
In this article we are going to take a look at options on how to deploy a standard PHP application to Azure App Service. This article is split into two parts – classical App Service running Windows and the new Docker-based App Service on Linux which recently got some really nice improvements towards PHP support.
Whenever you are collecting a date with Application Insights, it might be handy to have the ability to filter the telemetry based on currently signed in user. The documentation is quite confusing about it, so I decided to write an article and clear it up.
While working on a project, I stumbled upon an interesting issue – how to force the user to reauthenticate in an application – for example when accessing some sensitive information? While it may seem quite straightforward from the documentation of Azure AD, it is not that simple, and if you are using prompt=login to reauthenticate the user, I quite suggest you read on.
When building a Line Of Business (LOB) application, you are usually better off with implementing the customer’s current Identity Provider (IdP) which could be ADFS, Azure AD or some others. The benefits are clear – users use a single account for all the services, authenticate through a central point, can be more protected by conditional access policies and as a great benefit, you can leverage the existing data through Microsoft Graph for example. So while it is obvious why to use Single Sign On in your application, a little bit less discussed topic is about Single Sign Out (SLO).