Announcement

Collapse
No announcement yet.

HTTP Authentication with REST

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • HTTP Authentication with REST

    So I have finally succeeded at putting together my channels.

    As this was a particularly painful experience for me, I am going to attempt to provide some insight into what I have learned. I would love any feedback from the real experts out there since I am new and may mislead some at least a little with my story. This will leave a lot of things that don't work out, since I can't remember all the things I tried, but I will be concise with the things that do work.

    Step One - Create a channel -> channels listing in top left hand navigation box
    Step Two - The Summary Tab -> name your channel
    Step Three - The Source Tab ->
    - select HTTP Listener
    (I was testing using the post plugin for firefox)
    - select the address and port on which to listen
    - my channel is working and I have selected not to append
    the payload variable
    - I have selected no encoding
    - my respond from is set to the other 'side' of my channel
    which is an httpSender, you'll set this up in a minute
    Step Four - The Desitinations Tab ->
    - set connection type to http sender
    (I was accessing the REST service over HTTP)
    - set the url to which to send the request
    (eg. 127.0.0.1:6662 aka iport)
    - set the method to get
    (my REST service was providing read only access to
    start, I hear that Mirth is including other Methods
    in 1.8)
    - here I have send response to none. I don't know the
    difference between this reponse field and the respond
    from on the source tab
    - here I have excluded the response headers. I don't know
    that it is necessary here, but I am under the impression
    that they can interfere with parsing when they are
    included in an inbound xml encoded message to an http
    listener. (eg when you respond from the second channel
    which we will get to - it is an http listener as well and
    would send and xml reponse back from the rest service
    - adjust the transformer script -> link in the lower box of
    the left hand navigation panel
    - here I won't give you the full story, but search the
    forums for how to fill the 'message templates' tab in the
    transformer section, it involves grabbing some message
    output and pasting it
    - add a new transform step -> left hand nav box
    double click on the type cell of your new step, select
    javascript
    - use this magic
    Code:
    msg['Authorization'] = FileUtil.encode( ( new java.lang.String( msg['Authorization'].toString() ) ).getBytes() );
    * some details about this - FileUtil is a java class that
    has been made available through Rhino - read about Rhino,
    you can look that up on the forums
    * encode takes a byte array and the Java String class
    provides a conversion method
    * since String is in the java package, I can use it with
    the given syntax, if it was in another package I could
    not, read Rhino docs for details
    * there are a number of instance variables available in the
    javascript context which are poorly documented. eg
    message, msg and logger
    * in the given context, msg is an array representation of
    the incoming xml encoded data which includes the headers
    that I pass from the post plugin
    * the param I pass in is the string 'meass' which is my
    authentication info for my rest service
    * this needs to be Base64 encoded as per the http protocol
    specification (look up Basic HTTP Authentication - there
    is a great starter page on wikipedia)
    * set up a second transformer step called Authorization
    (this is the name of the Auth header variable)
    * set its Mapping field to msg['Authorization').toString()
    * use the drop down just above there and select 'add to
    channel map'
    * add a third transformer step - something here is probably
    redundant, but it works so I am letting it be for now
    * in the third channel set the value to msg['Authorization']
    * back to the main screen don't forget to save
    * add a new header variable name Authorization.
    * activate the value field by clicking on it, now drag the
    Authorization field from the code templates on the right
    into the field. There is a direct corrolation between
    what you do in the transformer scripts and what is
    available in the code templates here. Play with it if it
    isn't working like you think it is suppose to.
    * DON'T WORRY ABOUT THE SCRIPTS TAB YET - it does lots of
    cool stuff but we don't need it for this example

    Step 5 -> the other channel
    - set up a new channel
    - set respond to to none on the source channel
    - set the other fields to suit your needs
    - setting a request parameter that requires a restricted character like >,< etc
    * edit the transformer for this channel's output connector httpSender in my
    case
    * encodeURI('age:<:40') I set my Mapping value to this
    - it uses the javascript function encode URI
    - you could do lots of other stuff here using Java classes through rhino,
    but keep it basic for now
    - while you're here, set up your Authorization param and go through the copy
    paste excercise for the 'Message Templates' tab.
    - use channel Map again for both
    - I used a request var called q - and value - dragged and dropped from the
    templates of ${Parameters}
    - I also made a fix to my Authorization header param here - bet you were
    wondering about that! - I prefix it with Basic --- like so
    Basic ${Authorization} as a header param called Authorization
    - That is needed to comply with the expected header format.


    And HUZZAH we are done --- this probably won't work for you on the first go, but play with it, you probably aren't nearly as far off as I was when I started.

    Fieran Mason-Blakley

    Post edited by: fmason, at: 12/11/2008 15:35
    Fieran Mason-Blakley
    Standards Researcher
    Genologics Life Sciences

  • #2
    Re:HTTP Authentication with REST

    Thanks for posting this fmason, it looks like a good intro to how to handle HTTP as well as getting a new user started with Mirth.
    Jon Bartels

    Zen is hiring!!!!
    http://consultzen.com/careers/
    Talented healthcare IT professionals wanted. Engineers to sales to management.
    Good benefits, great working environment, genuinely interesting work.

    Comment


    • #3
      Re:HTTP Authentication with REST

      This post and the next are two channels communicating over http with basic authentication - a much cleaner version than my first go Channel_A-61027e84e620ddb3c45c07af67c722d5.xml (8277 bytes)
      Fieran Mason-Blakley
      Standards Researcher
      Genologics Life Sciences

      Comment


      • #4
        Re:HTTP Authentication with REST

        and the second channel channel_B-4c8ebe671919ce794f4e852587b98246.xml (6638 bytes)
        Fieran Mason-Blakley
        Standards Researcher
        Genologics Life Sciences

        Comment

        Working...
        X