#510 C# (.NET) Haystack Authentication Library - Released!

Matthew Giannini Thu 29 Jun 2017

Hi everyone. We are pleased to make available an open-source C# library for doing the new SCRAM haystack authentication. You can find the source code here:

https://bitbucket.org/skyfoundry/haystack-csharp

This is a very minimal implementation that currently only solves the authentication problem. We hope that in the future, we or members of the community who do a lot of .NET development will enhance it to support the full haystack data model.

Andrey Poltavets Mon 11 Sep 2017

Hi Matthew Good work! I've fixed basic auth and compatibility with nhaystack. https://bitbucket.org/minzdrav/haystack-csharp/commits/3f1b05568854ad4faeb17bdc2161151774f77c55

How we can integrate my changes to your repository? Btw, I would be happy to see your library on nuget.

Matthew Giannini Tue 12 Sep 2017

Hi Andrey - can you issue a pull request or send me a patch directly (I will email you offline)? I will try to get in incorporated as quickly as I can.

Andrey Poltavets Wed 13 Sep 2017

Hi Matthew. You can find patches in email message. Thank you for quick response.

Matthew Giannini Wed 13 Sep 2017

@Andrey - Thanks for the patches. I pushed them to the repo and they are available now.

Andrey Poltavets Wed 13 Sep 2017

Perfect!

Tyler B. Long Wed 28 Feb

Hey Matt,

Using the latest haystack-csharp version I seem to be having issues getting a json response from a server which is using haystack v2.0. The code below returns a result in the text/zinc format:

var uri = "http://someserver.com/api/demo/";
HClient hsClient = HClient.Open(uri, user, pass);
Dictionary<string, string> searchParams = new Dictionary<string, string>();

string result = hsClient.GetString("about", searchParams, "application/json", "application/json");

Console.WriteLine($"Result:\n{result}");

Using the RestSharp library and code below against the same endpoint I am able to get the expected json response:

var client = new RestClient("http://someserver.com/api/demo/about");
var request = new RestRequest(Method.GET);
request.AddHeader("Accept", "application/json");
request.AddHeader("Authorization", "Basic user:pass");

IRestResponse response = client.Execute(request);

Console.WriteLine($"Result:\n{response.Content}");

Let me know if this is not the proper venue for questions on the library. Happy to help contribute where I can. Thank you for your time.

-Tyler

Matthew Giannini Wed 28 Feb

Tyler - that is weird. Seems like you are doing the right thing. For this particular project I am more than happy to receive patches from the community. The BitBucket repos is at haystack-csharp. If you are able to debug it and come up with a fix, let us know, or send a pull request to that repo.

Tyler B. Long Tue 6 Mar

Hey Matt,

The haystack endpoint I was working with actually had two API endpoints. The one they were using for testing was the one not returning a proper json response so the issue I was seeing was not related to the haystack-csharp library. I was however able to find an improvement along the way and sent over a PR. Thank you for the help.

Matthew Giannini Thu 8 Mar

Thanks Tyler - I merged in your PR.

Tyler B. Long Mon 18 Jun

Hey Matt,

I have recently interacted with a 3rd party haystack v3.0 compliant server using this library. Presuming the HClient requests a json response, this lib's current implementation sets the Accept header to:

Accept: application/json; charset=utf-8

The assistance I need here is to confirm whether the charset=utf-8 portion for v3.0 should be presented in its own Accept-Charset header.

Stated another way, should the following Accept header be considered both haystack v2.0 and v3.0 compliant:

Accept: application/json; charset=utf-8

Happy to send over another PR to correct if needed.

Thanks, Tyler

Matthew Giannini Tue 19 Jun

Hi Tyler - So I'm assuming the issue is that the remote server does not like the charset=utf-8 being part of the mime type?

I think it is probably a bug to for the .NET library to force appending charset=utf-8. You can include that in the mimeRequest parameter of the HClient.PostString if you need to.

I'd be happy if you sent a pull request to correct this. Thanks!

Tyler B. Long Tue 19 Jun

That is correct. Adding charset=utf-8 to the Accept header causes their v3.0 implementation to return text/plain instead of application/json as the Content-Type in the response. I'll send over the correction for both HClient.GetString and HClient.PostString.

In addition, there is another minor correction to include in HClient.OpenHttpConnection along with some formatting. What code formatting freedoms might I assume? Is there a particular standard I should follow or are the standard VS 2017 format settings acceptable?

Matthew Giannini Wed 20 Jun

Hi Tyler - as far as code formatting, I would try to follow whatever we have in the files right now.

I'm not a .NET developer so I'm not sure what the standard conventions are. If you think the source is way off in terms of standards, I could see doing a separate pull request that just does reformatting. But don't mix formatting changes with bug fixes. Thanks!

Matthew Giannini Fri 10 Aug

@Tyler - FYI - I merged in your two outstanding pull requests. Thanks for contributing.

Aswin Ramakrishnan Tue 18 Sep

Hey Guys,

First of all - Thanks for this awesome .NET connector. It works beautifully!

Problem

Just wanted to point out something I ran into - I had an issue when using toJson(), where it was throwing an UnknownNameException: <ColumnName> error when the column name was null in the returned HGrid.

It was working fine with ToString() and toZinc() functions but throwing this error just for the toJson()

This was probably due to the function get in HRow.cs (line 75 - 85) which was -

// Get a cell by column.  If cell is null then raise
//    UnknownNameException or return  null based on checked flag. 
public HVal get(HCol col, bool bchecked)
{
    HVal val = m_cells[col.Index];
    if (val != null) return val;
    // Ian Davies - .NET port - this could cause a unknown name exception
    //              for a null value - back to previous comment
    if (bchecked) throw new UnknownNameException(col.Name);
        return null;
}

I believe this is good / the intended functionality with the bChecked parameter.

But I noticed that in line 148 of HJsonWriter.cs, we get HVal by doing the following

HVal val = dict.get(name);

Because of this, the bChecked value was getting set as true by default and it was causing the error.

Solution

So I did this to fix it -

HVal val = dict.get(name, false);

Since this is a super minor fix, just wanted to point out here (if you guys would like to fix it from your end instead of a PR).

Once again, thanks for this connector. Awesome work!

Ian Davies Wed 19 Sep

Hi Aswin,

Thanks this small issue fell through the unit tests and have not had time to further my own project where I am looking at using the .NET client, so did not notice it in furthering my own application use. Created a pull request to merge this change after completing the unit tests after making the change (sorry got the name wrong looking at the thread prior to this one when making the changes in sourcetree - my apologies)

Thanks again for your finding and complements on the work done to this library.

@Matthew you should find a new pull request for this with the change.

Kind Regards

Ian Davies

Matthew Giannini Thu 20 Sep

@Ian @Aswin - I have merged the pull request in that contains this fix

Login or Signup to reply.