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).
Recently I have been working on a project in ASP.NET Core and DotVVM accompanied by a WebJob using Azure WebJob SDK. The idea behind publishing was that whenever I push code to the repository (VSTS in my case), App Service would pull the code, build it and deploy it automatically (this is achieved by setting up Continuous Deployment). This method works just great for ASP.NET Core application, however when accompanied by a WebJob, things weren’t as smooth as I was expecting them to be.
If you have been watching Connect(); or if you read the Azure blog, you should be aware by now, that Azure has recently introduced a pretty cool service called App Service on Linux. It is probably also not going to be a surprise to you if I tell you that it is being powered by Docker. And that is not the only great thing about it – you can also bring your own Docker image into App Service on Linux!
cURL is one of the most common ways to make HTTP requests from PHP code. When you make regular http:// calls everything is alright, but when you decide to go with https://, you need to configure few things on App Service manually for it to work correctly.
There are many different articles on the internet about how to make an application faster when hosting it on Azure. This has been a real pain point with big PHP applications or applications which involve a lot if IO operations – like loading modules with Node.js. Recently, I was working with one startup and they approached me with a very interesting issue: Their Node.js application was running about 35x faster on Heroku than on Azure App Service and that is what actually made me to write this article.
When speaking of modern development nowadays, we can hear words like DevOps and as part of that, Continuous Integration (if you never heard about it, you can read more about it here). Anyways, today I am going to show you how to set up a build definition for a PHP project stored in Visual Studio Team Services and then the publication to an Azure Web App or a physical server.
During the last couple of weeks, users started noticing certain issues with an application that I develop on Microsoft Azure using PHP and Azure Web Apps. In general, the application is using an OAuth2 library to connect to a custom identity provider, the access token, refresh token and others are stored in $_SESSION. From the last sentence, you could have noticed two keywords – OAuth2 and refresh. The users started noticing an issue that after some time of working with the application (also the IdP was generating loads of useless token pairs), that they had to constantly relog. After turning on the logs, doing some diagnostics and trying to reproduce the issue, it was pretty clear – something fishy is going on with sessions.