Monday, December 18, 2017

Getting last modified software on Windows using PowerShell

Getting the list of the last modified software on Windows is actually simple, if using PowerShell
Photo by Miti on Unsplash
Whenever I get requests like "hey, how can I get the lastly installed software on my machine?", I try to resolve them with code and as simple as possible. Turns out that on Windows, PowerShell can be an excellent tool for scripts like those. On this post, let's address that using PowerShell and review how it became a fun, simple and quick exercise.

Using Get-WmiObject

The Get-WmiObject cmdlet is what we need to get Windows diag information. By combining it with Export-Csv we can export all installed software on our machines with:
Get-WmiObject -Class Win32_Product | Export-Csv installed.csv

Using Get-ChildItem

The next part consists in using the Get-ChildItem cmdlet to filter out our exported data. That can be done with:
# getting last modified files
Get-ChildItem C:\ -rec | sort LastWriteTime | select -last 1000 | Export-Csv files.csv

Conclusion

Doing this simple exercise was fun, simple and quick using PowerShell. Don't know PowerShell yet? I would urge you to take a look and learn it (even if just the basics). PowerShell is a powerful tool used extensively in devops on Windows, Azure and Linux.

Oh, and yes, I really don't miss the days before PowerShell!
Posted by
Labels: , , , , ,

Monday, December 11, 2017

PowerShell - The server committed a protocol violation

Let's understand what that error means and review 3 different ways to fix it.
Photo by Max Rovensky on Unsplash

This sort article details a good trick for those getting the following error in PowerShell: 
The server committed a protocol violation
After googling ducking around, I found three different solutions for this problem:
  1. Modifying your powershell.exe.config;
  2. Modifying your request in order to avoid it stopping if your url is invalid in .NET
  3. Modifying your request in order to avoid it stopping if your url is invalid in PowerShell.
Let's review each of them and understand a little more about the problem.

    Solution 1 - Modifying powershell.exe.config

    This solution will apply to all PowerShell requests so use with caution. Also, this solution is not portable so, if you plan to run this script on a machine you don't have admin access to, this solution will probably not work.
    <system.net>
    <settings>
    <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
    </system.net>

    Solution 2 - Modifying your request in .NET

    To modify your request, have the code below before you actually run Invoke-WebRequest:
    $netAssembly = [Reflection.Assembly]::GetAssembly([System.Net.Configuration.SettingsSection])

    if($netAssembly)
    {
        $bindingFlags = [Reflection.BindingFlags] "Static,GetProperty,NonPublic"
        $settingsType = $netAssembly.GetType("System.Net.Configuration.SettingsSectionInternal")

        $instance = $settingsType.InvokeMember("Section", $bindingFlags, $null, $null, @())

        if($instance)
        {
            $bindingFlags = "NonPublic","Instance"
            $useUnsafeHeaderParsingField = $settingsType.GetField("useUnsafeHeaderParsing", $bindingFlags)

            if($useUnsafeHeaderParsingField)
            {
              $useUnsafeHeaderParsingField.SetValue($instance, $true)
            }
        }
    }

    Solution 3 - Modifying your request in PowerShell

    This is probably the simplest. Just run the line below:
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }

    Conclusion

    On this post we reviewed three different ways to resolve a problem in PowerShell. Don't know PowerShell yet? I would urge you to take a look and learn it (even if just the basics). PowerShell is a powerful tool used extensively in devops on Windows, Azure and Linux.

    See Also

    Posted by
    Labels: , , , , ,

    Monday, December 4, 2017

    ASP.NET - How to allow anonymous requests on secure endpoints

    How to allow unauthenticated requests on authorized endpoints using ASP.NET? Let's take a look.
    Photo by Philipp Katzenberger on Unsplash

    In a previous article, I described how to extend the ASP.NET pipeline with custom security. Turns out that certain endpoints were still required to operated unauthenticated. How do we allow those requests to be processed? The solution relies on:
    1. Decorating the security attribute with the AllowAnonymous as discussed on the previous post.
    2. Detecting the current request is an ActionExecutingContext and allowing the request to proceed conditionally.
    Let's see how we can write a custom RequirePermission attribute to solve that problem.

    Writing a custom ActionFilter Attribute

    Writing a custom ActionFilter attribute isn't complicated. Here's one code that demonstrates how to do that elegantly:

    Using the Attribute

    Next, we ca use our attribute to decorate our actions so it runs as soon as our endpoint is hit:

    Conclusion

    This was a quick post extending the previous discussion on how to implement custom action filters to have a better control over the requests agains our application. On this post I explained how you could intercept requests on your application and react to them using these attributes. For a complete understanding of the project, please the original discussion

    See Also

    Posted by
    Labels: , , , , ,

    About the Author

    Bruno Hildenbrand