Griffin Framework homepage

Griffin Framework just got a new homepage.

It’s still basic, but will continue to grow. I’ll also commit it in the “homepage” branch at github. Feel free to add improvements to it.

  • Matt

    Hi Jonas,
    Thanks for the time and effort taken in building this framework.
    I’m having a play around for an EDI type project i’m working on. In short, I need a process that will listen on a secure HTTPS channel for a body of text to come in. This text will be validated against either EDIFACT messaging or our bespoke formats.
    So far I have the server set up and it listens. Then i’m stumped.
    The message will be a body of text passed through in a POST request. I can’t for the life of me figure out how to get the message to be received through the framework – i’m assuming it’s something to do with the message decoding/encoding as part of the initial server setup.
    I’m using
    var listener = new Griffin.Net.Protocols.Http.HttpListener();
    Everything else is pretty much standard as per your examples.
    What should I be using for listener.BodyDecoder for the text based message to propogate through? I would really appreciate any help you can give.

    Also, in an ideal world I would have the user authenticate with username/password when they fire up their client – i’m struggling to find documentation that would help me do this using your framework.

    Again, any help you can give would be immensely appreciated.
    Regards
    Matt.

    • That’s a bug. You should be able to just read the Body stream when no decoder is specified. I’ll update the source code.

      However, to make it work with the current version you can create a serializer like this:

      https://gist.github.com/jgauffin/d595865a538af306d99d

      • Matt

        Hi Jonas,
        Thanks for that. I’ve coded as per your code segment and the message comes through as expected. Wonderful!
        Are you able to offer any guidance on the HTTP authorisation I mentioned? I need the user to pass thrugh a username and password through the HTTPS channel upon which I will validate against stored values in a database table. I just need to know how I actually ‘receive’ those credentials into the server side.
        Also, and I apologise for bombarding you, but on your homepage for the framework (http://griffinframework.net/), there is a section for logging that appears to be empty – i’m wondering if your logging routine allows for logging to files? Might you have some samples to help with that?
        If it will log to files, does the file just get bigger and bigger when used, or would it have the ability to rollover when a certain size is hit? Sort of like using logrotate under linux. i.e. file initialy called httpserver.log, but once it hits a certain file size (let’s say 20MB) it dumps the current version to httpserver.log.1 and creates a new empty httpserver.log to receive the next log data.

        Finally, when you mentioned that you would update your code, did you mean just the github sourcecode, or would the nuget be updated too?

        Once again, thank you for your time and attention – your help is invaluable.
        Regards,
        Matt.

        • Here is basic authentication: https://gist.github.com/jgauffin/e5f5693849287d70942f.

          There are some pre-built authenticators. I have however not created an extension point for them yet. But you can use them like in my gist: https://github.com/jgauffin/Griffin.Framework/tree/master/src/Griffin.Framework/Griffin.Core/Net/Protocols/Http/Authentication

          I’m going to both commit my changes and update the nuget package.

          • Matt

            Morning,
            That works great. Well, all but a little bug but i’m sure it’s down to my interpretation rather than your code.
            The code :

            if (authenticateHeader != null)

            {

            var bytes = Convert.FromBase64String(authenticateHeader);

            var parts = Encoding.ASCII.GetString(bytes).Split(‘;’);

            throws a wobbly on the Convert line (AuthenticateHeader is something like ‘Basic bXl1c2VyOm15cGFzc3dvcmQ=’ – it seems the ‘Basic ‘ part is causing it to fail conversion. Do I always just need to strip out up to and including the first space?
            I will always use basic authentication, so i’m guessing I don’t need to worry too much.

            Also, the part ‘Thread.CurrentPrincipal = new GenericPrincipal(new GenericIdentity(username), new string[0]);’ stops any further requests needing authentication, so I guess I need to look at handling each message received within it’s own thread.

            Was there any facility with your logging routines to log directly to a file?
            Thanks.

          • That right. Incorrect of me. you need to remove the “BASIC ” part first 🙂

            As for the principal part, it should not prevent any other requests. What I do is that I store the authenticated user in the channel data. That data is only specific for the current HTTP connection. Thus anyone else connecting should get their own authentication procedure. Browsers tend to reuse connections for different tabs. To be sure simply use two different browsers to verify that both must authenticate.

          • Matt

            You’re absolutely right – it was me just making an assumption, and expecting each tab to authenticate separately – tried through a secondary client and it does exactly what I need it to do. Thanks for that.
            I’m guessing the logging isn’t going to do file based at the moment 😉

            You mentioned earlier, regarding authorisation, that you haven’t created any extensions – is this something you have in the pipeline? The way you’ve explained does what I need, but just wondered.

            How soon will you have commited your changes for both source and nuget?
            Thanks Jonas,
            Matt.

          • I use log4net for most projects. At this point the logger namespace is just used to allow the developer to be able to get the log entries from Griffin Framework to their favorite logging library.

            However, I’ve written a more complete implementation in the old version of Griffin.Framework: https://github.com/jgauffin/griffin/tree/master/Source/Griffin.Logging. I’ll merge it into the new version as soon as I can. It includes a file logger that wraps on date.

          • Matt

            That sounds great. I’ll key an eye out for that update.

            Jonas, I really appreciate all the help you’ve given here. It has helped me enormously. Thank you.

          • Matt

            Looked at log4net – pretty good! Thanks for the tip.

          • Matt

            Hi Jonas,
            Any news on the release of your updated framework and it’s nuget?
            Thanks

          • Just pushed it.

  • Matt

    Hello again,
    I’ve got another issue – not sure if it IS actually an issue or not though. Might, again, be down to my lack of knowledge when it comes to dealing with HTTP.
    My test connections are all coming via a browser, either typing the full http string in the address bar, or via a chrome extension such as DHC or PostMan.
    When I click send, or press enter in the address bar, the httplistener seems to receive a client connect, a disconnect and then another connect.
    I have registered handlers against ClientConnect/Disconnect to write a message when each is received.

    Upon each separate connect, a different port on the client is reported.
    Is this a bug? Or am I doing something wrong?

    static void Main(string[] args)
    {
    var certificate = new X509Certificate2(“mycert.pfx”, “password”);

    var listener = new Griffin.Net.Protocols.Http.HttpListener();
    listener.ChannelFactory = new SecureTcpChannelFactory(new ServerSideSslStreamBuilder(certificate));
    listener.MessageReceived += OnMessageReceived;
    listener.ClientConnected += OnClientConnected;
    listener.ClientDisconnected += OnClientDisconnected;
    listener.BodyDecoder = new PlainTextSerializer();

    listener.Start(IPAddress.Any, 8080);
    Console.ReadLine();
    }
    private static void OnClientConnected(Object sender, Griffin.Net.Protocols.ClientConnectedEventArgs e)
    {
    log(“Client connected from {0}”, e.Channel.RemoteEndpoint.ToString());
    }
    private static void OnClientDisconnected(Object sender, Griffin.Net.Protocols.ClientDisconnectedEventArgs e)
    {
    log(“Client disconnected”);
    }
    private static void OnMessageReceived(ITcpChannel channel, object message)
    {
    }

  • Matt

    Hi Jonas,
    I’m back again. I don’t support you’re able to to offer any tips on setting a HttpListener.BodyDecoder that would retrieve a text/plain body (as you did for me below) but also key=value type parameters (like your UrlFormattedMessageSerializer / UrlDecoder) combined?
    I’m wanting to be able to easily differentiate between the URL parameters and the bulk message as sent.
    Currently, in the example you gave, the body is returned as for FormAndFilesResult with the fkey as EDI and the value as per what was sent.
    I need the user to be able to pass parameters along with the URL and have them captured in the onMessage handler so I can process accordingly.
    I’m getting a bit lost.