Testing a REST API with Powershell

With the following Powershell script, you can issue a POST request to a REST endpoint

add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@

[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

$uri = 'https://myurl.com/v1/MyResource?param=true'

$body = 
'{
    "products": [
        {
            "productId": 1,
            "quantity": 0
        },
        {
            "productId": 2,
            "quantity": 0
        }
    ]
}'


$response = Invoke-WebRequest -Uri $uri -Method POST -Body $body -ContentType 'application/json; charset=utf-8' 
$response.Headers

"Clone in Desktop" doesn't launch GitHub for Windows

"Clone in Desktop" wasn't launching GitHub for Windows.
Fortunately Joe Freeman solved it.

You either
a. Log in to GitHub in the Web Browser before clicking the "Clone in Desktop" link
b. Drag the URL of the repository to GitHub for Windows

Galaxy Tab S doesn't connect to ADB (Android Device Bridge)

After receiving a new Galaxy Tab S, I noticed it would not connect to Eclipse or ADB for debugging.

(I had enabled Developer options by clicking on Settings > General > About Device > Android Version 7 times).

The solution is that you have to download the USB driver from Samsung's site. This then enables the following drivers:

Sitecore 6.6, Web API 1.2 and the message "An attempted to execute remote call was declided, because current mode is 'off'"

We are running Sitecore with MVC and installed the Web API 1.2.

When accessing the URL
http://<hostname>/-/item/v1/?query=/sitecore/content/*

from within Chrome and Postman it was running an error page.
After some extensive reading, experimenting, writing a custom pipeline processor and using Reflector, I finally solved it.

Firstly I turned on logging to ALL in App_Config\Sitecore.log4net.config.

This showed the following error message in the event log:

"An attempted to execute remote call was declided, because current mode is 'off'"

er... this should mean "declined", but never mind. Carrying on:

Reflector indicated that the CheckMode processor found the itemwebapi.mode setting was turned to "Off".

But hold on, my settings were on:
Include\Sitecore.ItemWebApi.config:

<site name="website">
        <patch:attribute name="itemwebapi.mode">StandardSecurity</patch:attribute>
        <patch:attribute name="itemwebapi.access">ReadOnly</patch:attribute>
        <patch:attribute name="itemwebapi.allowanonymousaccess">true</patch:attribute>
      </site>

So then I wrote a processor to fit within the pipeline to evaluate the problem.
The following class was written and added to a class library:

using System;
using System.Diagnostics;
using Sitecore.Diagnostics;
using Sitecore.Pipelines.HttpRequest;

namespace TestPipeline
{
    public class TestProcessor : HttpRequestProcessor
    {
        public override void Process(HttpRequestArgs args)
        {
            var context = args.Context.Items["Sitecore.ItemWebApi.Context"];
            Console.WriteLine("Hello World");
        }
    }
}

the class library requires references to Sitecore.Kernel and System.Web.

Using reflector, it can be seen that the Web API settings are loaded in SetRuntimeSettings, which runs after SiteResolver:

<processor type="Sitecore.ItemWebApi.Pipelines.HttpRequest.SetRuntimeSettings, Sitecore.ItemWebApi" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel']" />

Therefore the pipeline was inserted after SiteResolver:

<processor type="Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel" />
<processor type="TestPipeline.TestProcessor, TestPipeline" />
<processor type="Sitecore.Pipelines.HttpRequest.UserResolver, Sitecore.Kernel" />

A debugger was then attached to the wp3 process and a breakpoint put within the processor.
Looking at args.Context.Items["Sitecore.ItemWebApi.Context"].Settings.Mode it was indeed turned to off and not StandardSecurity.

It was then determined that in the Web API config the site had the default sitename:

<site name="website">

whereas in Include\Sitecore.SiteDefinition.config the sitename was patched to something else:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <sites>
      <site br="" name="checkout" patch:instead="site[@name='website']">
</site></sites></sitecore></configuration>b

Removing Include\Sitecore.SiteDefinition.config fixed the problem.
To keep the file, the following attributes were added:

itemwebapi.mode="StandardSecurity"
itemwebapi.access="ReadOnly"
itemwebapi.allowanonymousaccess="true"

Solved: The WebAPI config was assuming the default site name "website" whereas this had been configured to something else.

Firebug remembers old / deleted breakpoints

 

In Firefox, go to URL about:support

Check the Profile Directory

Open containing folder

Go into folder firebug

Delete breakpoints.json

MSMQ code sends message, doesn't error, but doesn't show

http://stackoverflow.com/questions/9911843/message-does-not-reach-msmq-when-made-transactional

For queue's that you have created as transanctional, you must use the version of Send() that includes the MessageQueueTransactionType parameter. The biggest frustration with this is that it doesn't throw any exceptions or errors as you have seen, but the message just doesn't ever show up.

So, in your code, change:

helpRequestQueue.Send(theMessage); 

to

helpRequestQueue.Send(theMessage, MessageQueueTransactionType.Single); 

 

FXCop and built-in rules: CA1723 and "Use preferred terms" for Canceling

FXCop has some built-in rules for complaining about a UK spelling of "Canceled", e.g. "Cancelled".

If you override the section

<Term PreferredAlternate="Cancelled">canceled</Term>

it doesn't work and it still complains about the word "Cancelled".

However if you set it to

<Term PreferredAlternate="Andy">canceled</Term>

it then raises CA1723 and suggest you change it to "Andy".
If you remove the line completely it still complains about the word "Cancelled" and suggests "Canceled".

So the behavior is relying upon a default rule and error cannot be configured out using the PreferredAlternate section of the CustomDictionary; it looks like it can only changed to an alternative spelling.

However there is a way! Looking at the FX Cop IL, it can be seen that if you set the US spelling as an unrecognized term

<Unrecognized>
      <Word>canceled</Word>

then it overrides the built-in rule and the error disappears!