Upgrading your Neo4J from XXX to 2.2.0–having authorization trouble?

Originally posted on: http://geekswithblogs.net/cskardon/archive/2015/03/27/upgrading-your-neo4j-from-xxx-to-2.2.0ndashhaving-authorization-trouble.aspx

I’ve recently upgraded one of my Neo4J dbs from 2.1.7 to 2.2.0, and instantly ran into troubles with the new Authentication that the db now has. You’ll notice it when you first login to your browser (http://localhost:7474/) and get asked for a login name and password. Of course, you can turn off authentication via the settings (conf/neo4-server.properties) by changing the ‘dbms.security.auth_enabled’ value to false, but now we’ve got it, we should use it!

Luckily neo4jclient already allows us to pass in basic auth via the uri, so we can do something like:

var client = new GraphClient(new Uri("http://user:pass@localhost.:7474/db/data"));
client.Connect();

9 times out of 10, that’ll work just fine for you, the problem is if your password has a character in it that the Uri constructor can’t parse – now I’m sure you can escape the character – but I’ve been unable to find out how, so something like:

new Uri(http://user:pass#@localhost.:7474/db/data)

will fail with a ‘UriFormatException: Invalid URI: Invalid port specified.’ message (I’ve added a ‘#’ to the password).

What to do???

Spiffily – the GraphClient has another constructor that takes in an IHttpClient, so we can create our own version that injects the Authorization header into any (and all) requests to the db:

private class HttpClientAuthWrapper : IHttpClient
{
    private readonly AuthenticationHeaderValue _authenticationHeader;
    private readonly HttpClient _client;

    public HttpClientAuthWrapper(string username, string password)
    {
        _client = new HttpClient();
        if (string.IsNullOrWhiteSpace(username) || string.IsNullOrWhiteSpace(password))
            return;

        var encoded = Encoding.ASCII.GetBytes(string.Format("{0}:{1}", username, password));
        _authenticationHeader = new AuthenticationHeaderValue("Basic", Convert.ToBase64String(encoded));
    }

    public Task<HttpResponseMessage> SendAsync(HttpRequestMessage request)
    {
        if(_authenticationHeader != null)
            request.Headers.Authorization = _authenticationHeader;
        return _client.SendAsync(request);
    }
}

Which is used like so:

var client = new GraphClient(
    new Uri("http://localhost.:7474/db/data"), 
    new HttpClientAuthWrapper("user", "pass#")
    );
client.Connect();

All authorized and happy!

Extensionising Wpf (or Chris’ fun with Extension methods and Wpf)

To be honest, it’s not really trouble using, or indeed writing extension methods, I don’t really have any troubles writing them, it’s more what I wanted to do with them that has bugged me.

As everyone who gets into writing WinForms / WPF apps knows, there will come a point where you will need to partition the work you’re doing to another thread. The usual reasons (so you can do other things, so the UI doesn’t lose it’s interactivity etc) apply.

Once you’ve entered this world you may even want to update the UI from within the thread – maybe it’s just a simple thing like enabling a button, changing the text on a label (etc). It’s quite a common thing to do and as such you can find shed loads of blogs, articles on the whys and wherefores of achieving those goals. I’ve been a WinForms developer for oooh, 4 years now, with the last year being a crossover of WPF / WinForms development. As a consequence I’ve done this quite a lot, and tend to find I have the same methods littering my code for achieving these goals:

private delegate void UpdateControlVisibilityDelegate(Control control, Visibility visibility);
private void UpdateControlVisibility(Control control, Visibility visibility)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

Obviously, this is called pretty easily via the code:

UpdateControlVisibility(_myLabel, Visibility.Hidden);

Nicely, even if this is called from another thread, it avoids the cross-threading issues.

But what about making it better? Using the tools available and going all Extension method on it’s arse??

Extension methods are (I think) great, even if Resharper is currently screwing up the intellisense for them! Anyhews, the basic signature we’ll be looking at for the method would be something like:

public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
/* Code */
}

Two things different from the previous, first, it’s static, second it’s got the ‘this’ keyword in front of the ‘Control’ argument. OK, so now lets just plug in the code…

private delegate void UpdateControlVisibilityDelegate(Control control, Visibility visibility);
public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

Ah. The biggest problem is that the method uses the ‘Dispatcher’ property of the Window class. As the extension method has to be in a static class, we don’t have access to the Dispatcher property… so… should we pass it in?

public static void UpdateControlVisibility(this Control control, Visibility visibility, Dispatcher dispatcher) { /**/ }

We could. It would work (or at least in my tests seems to), but would be a bit messy, ideally we only want to pass in the Visibility argument (remember as it’s an extensibility method, the ‘control’ part isn’t ‘passed in’). So. What to do? Luckily, the ‘Dispatcher’ property is actually on the Control itself, so we can modify the method call to be something like:

public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
if(!control.CheckAccess())
{
control.Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

The only real thing of note is that we’re using the ‘CheckAccess()’ method of the control rather than the Dispatcher’s. No real reason, just shorter to type, and does the same thing (or so reflector tells me 🙂 ).

So, now we can just get our Control based, err, controls to have their Visibility changed safely:

_myLabel.UpdateControlVisibility(Visibility.Hidden);

Good thing is that we can just whack this code into a utility project and utilise it where we want.

So – is this all good? Have we solved the problems of the world? No, sadly not. There are some caveats which you should be aware of. I originally attempted this so I could ‘Show()’ a Window safely. This led to me writing the following:

private static void ShowSafelyDelegate(this Window window);
public static void ShowSafely(this Window window)
{
if(!window.CheckAccess())
{
window.Dispatcher.Invoke(DispatcherPriority.Send, new ShowSafelyDelegate(ShowSafely), window);
return;
}
window.Show();
}

I was using this like this (you’ll have to bare with the threading here, it’s important to the story..):

///Handles the click of the button, gets the data on a new thread.
private void _btn_Click( object sender, RoutedEventArgs e )
{
Button b = sender as Button;
if(b == null)
return;
Thread t = new Thread(GetData);
t.Start(b.Tag);
}


///Gets the data and shows it in a
///The information to retrieve the data with.
private void GetData(object obj)
{
RetrievalInfo ri = obj as RetrievalInfo;
if(ri == null)
return;
DataTable table = DbUtils.GetData(ri);
WndwResults wr = new WndwResults(ri, table);
wr.ShowSafely();
}

Now, as we can see, the ‘GetData’ method is run on a seperate thread and constructs a WndwResults Window, and displays it (using the ‘ShowSafely’ method. Looks fine, but when run, will throw a tiswas and give you an:

InvalidOperationException
"The calling thread must be STA, because many UI components require this."

OK, so lets set the Apartment state of the thread to be STA…

Thread t = new Thread(GetData);
t.SetApartmentState( ApartmentState.STA );
t.Start(b.Tag);

GO!

ARGH!!!

LoaderLock detected
"Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang."

???

What the hell does this mean??
Turns out that the Loader Lock is a system wide lock which Windows uses to load / unload dlls (http://www.lenholgate.com/archives/000369.html). As to what it’s doing here, well, I need to spend some more time investigating that. However, more importantly right now is what we can do about it?

Well, we can disable the Managed Debugging Assistant for the LoaderLock exception (via the ‘Debug -> Exceptions’ menu option), but when we do this, we see the Window we’re loading flash up and then dissapear – which isn’t exactly what we want… The other option is to change the code.

In my initial code, I created the WndwResults Window in the new thread. If I take this back a bit further, and construct the WndwResults in the main thread, (not ‘Show’ it, but just construct it) then we’re ok:

/* Simplified example */
{
WndwResults wr = new WndwResults();
Thread t = new Thread(ShowWindow);
t.Start(wr);
}


private void ShowWindow(object o)
{
Window w = o as Window;
w.ShowSafe();
}

The above code works fine, and that’s because we’re not constructing the Window in the new thread. Of course the issue here is that I can’t now pass the data into the constructor, which costs me a few things – use of ‘readonly’ for the members, and other such things. But we can live with that.

Soooo….

We add a ‘SetData’ method to the Window:

public void SetData(DataTable table, RetrievalInfo ri){ /*....*/ }

and, going back to our previous code:

///Gets the data and shows it in a
///The information to retrieve the data with.
private void GetData(object obj)
{
RetrievalInfo ri = obj as RetrievalInfo;
if(ri == null)
return;
DataTable table = DbUtils.GetData(ri);
_wndwResults.SetData(table, ri); //
_wndwResults.ShowSafely();
}

Run the code… and… FFS!!!

InvalidOperationException
"The calling thread cannot access this object because a different thread owns it."

Of course it does! Hmmm, not a lot can be done in this situation, because the SetData (in my case) sets a couple of DependencyProperties, which in turn update the UI.

What can be done though? Well – we can make the SetData method literally only set member variables, and then attach to the ‘Loaded’ event of the Window in it’s own constructor, so… if it originally did this:

public void SetData(string message)
{
_lbl.Content = message;
}

Now it needs to do this:

//First add the member:
private string _message;


//Second add to the constructor of the Window and event handler.
public Window1()
{
InitializeComponent();
Loaded += Window1_Loaded;
}


//Handle the event...
private void Window1_Loaded(object sender, RoutedEventArgs e)
{
_lbl.Content = _message;
}


//Finally, modify the SetData method to actually set the data.
public void SetData(string message)
{
_message = message;
}

Phew! Lots of stuff to do, and that’s just for setting a label!

What are the conclusions of this epic of blog posts?
Well, quite frankly, going down the extension method route, whilst informative in learning how the threading works (well, a bit) has given me some useful methods, but, there are a lot of caveats that a Window has to adhere to, to make it work properly.

I’m going to persevere with this though, I reckon I can at least get some decent set of utility extension methods (for example the setting visibility one) for WPF controls. I’ll keep you posted – you never know, it might even be more frequent than once a month!

Ternary operators don’t work with nullable value types?

I’ve got the following situation:

DateTime? myDt = (DateTime) row["Column"];

This fails when retrieving a DBNull value, so we check for that:

DateTime? myDT = (row["Column"] == DBNull.Value) ? null : (DateTime) row["Column"];

This won’t compile, however doing:


DateTime? myDT;
if(row["Column"] == DBNull.Value)
myDT = null;
else
myDT = row["Column"];

works fine, now, I realise I can simplify that statement, but, for the purposes of this post, it is a closer match to the ternary operator.

Why won’t the ternary op work with the value type? It works perfectly with a string…

Missing format specifier.

I’ve been practicing my F# recently – I took a gap for a little bit, and just got back into it. I’ve been working through my ‘Foundations of F#’ book, and have hit a slight snag.

There is one line of code I can’t get to compile, I get the ‘Missing format specifier.’ error for the following line:

let print x = printfn “A%” x

The intellisense highlights under the “A%” bit.. Any ideas?

The hunt continues!
Update – worked it out, it should be “%A” rather than “A%” – looks like a typo!!

Invoking UI Changes in WPF

Again another reminder, in WinForms I would have done:

private delegate void UpdateUiTextDelegate(Control control, string text);
private void UpdateUiText(Control control, string text)
{
if(InvokeRequired)
{
Invoke(new UpdateUiTextDelegate(UpdateUiText), new object[] {control, text});
return;
}
control.Text = text;
}

Using the same delegate we need to use the Dispatcher.Invoke method – this is (as far as I’m aware at the moment) the sort-of equivalent of the Invoke method on a Form.


private void UpdateUiText(Control control, string text)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateUiTextDelegate(UpdateUiText), control, text);
return;
}
control.Text = text;
}

To be honest, I think I’ve read somewhere that the Dispatcher isn’t equivalent – but it does the job for now… I need to read into it more!

Enabling / Disabling buttons in WPF

I’m really only putting this in to remind myself — having come from a WinForms background, I’m used to:

_btnOK.Enabled = false;

but in WPF this is:

_btnOK.IsEnabled = false;

For some reason I (without fail) forget this!

WPF Resources from other DLL’s

I spent a little bit of time trying to figure this out, to be honest – it’s available in quite a few locations on google, but I thought I’d add it here as well. The basic problem is, you have your template / theme etc for your control in a separate project;

MyThemes : DateTimeThemes/Theme1.xaml etc

and you want to use this as a resource for your control, how?

You add into your Resources element (be it in Window.Resources or UserControl.Resources), like so:

<ResourceDictionary Source="/MyThemes;component/Themes/Theme1.xaml" />

What’s important here is that the word ‘component’ is as spelt, you don’t replace it with anything (like ‘MyComponent’ for example), just leave it as is.

/MyThemes

is the name of the dll, which isn’t necessarily the name of the project – (though that would only change if you’ve changed those properties).

Production LINQ!

I’m happy today as I’ve written my first bit of Production LINQ code in the form of LINQ-to-XML.
It’s not the most complicated bit of code – only a grabbing of data from a file, but it does do what it says on the tin – uses C# 3.0 and (unfortunately) causes Resharper to complain on a constant basis 🙂