Web Service: authentication with cookies

I have implemented many third party Web Services in HP SM without much issue escept in one instance. It turns out the Web Service used cookies for the authentication; you were supposed to send a regular message with some credentials and then they sent a reply and a cookie that was supposed to be attached to subsequent requests or something like this. The documents about implementing Web Services in SM don't cover this and only briefly mention it but give no examples or much information.

Does any one has en example of how to get this working?

Thank you

  • hello Stanum

    hope you are doing well.

    could you please let me know if you are using SSL, loadbalancer?

    when cookies are send over SSL, they should have the secure flag set.

    can you attached a screenshot? the steps you are follow?

    best regards.

  • Hi,

    Web services are using keepalive (as defined in HTTP 1.1)  with a cookie JSESSIONID.

    On the first successfully authenticated request, SM servlet creates a session to process it. For this all the login routines has to be processes - which is time-taking.

    Keepalive now means that the session is kept open even the response has been sent - waiting for new requests. Therefore the first response uses a "Set-cookie" header with the JSESSIONID cookie. When now another request setting "Cookie" header with this cookie, the session will serve the request.

    In debughttp trace you can see the HTTP header messages.

    The sm.ini parameter "maxKeepAliveRequests" can be set to limit the number of keepalive request before automatic closure of this session. This is actually a tomcat parameter - so you may read more about it in help server, but also on apache.org.

    SSL and so on complicates the situation - I don't know how this is working then.

    Armin

     

  • Hi Stanum-Igalan,

    Do you mind to let us know what is the document you are checking for this information? I've seen some documents with examples but probably those won't be exact for you third party tool but at least can give you some ideas. Check the document release data on the first, second or last page and let me know.

    I'll look for an example for you. If possible let me know what third party tool you are using.

    Regards,

  • Hi,

    I guess this information as reference can be useful (If you have the latest Web Services Best Practices guide it's included there)

    Keep-Alive example for Service Manager

    The following shows an example of the code for using Keep-Alive with Service Manager.

    ================================================================

    client request:

    POST /SM/7/ws HTTP/1.1

    accept: application/xop xml, text/xml image/gif, image/jpeg, *; q=.2,

    */*; q=.2

    authorization: Basic ZmFsY29uOg==

    soapaction: "Create"

    connection: Keep-Alive

    SM server response:

    HTTP/1.1 200

    Set-Cookie: JSESSIONID=ED61093038F9FF8CE9CF44E34C9366AC; Path=/SM

    Keep-Alive: timeout=1200000, max=1000

    Connection: Keep-Alive

    Content-Type: text/xml;charset=utf-8

    Content-Length: 2112

    .....

    Then you need to echo back the JSESSIONID for each client use the following:

    POST /SM/7/ws HTTP/1.1

    accept: application/xop xml, text/xml image/gif, image/jpeg, *; q=.2,

    */*; q=.2

    authorization: Basic ZmFsY29uOg==

    soapaction: "Retrieve"

    connection: Keep-Alive

    cookie: JSESSIONID=ED61093038F9FF8CE9CF44E34C9366AC; Path=/SM;

    ....

    ================================================================

    I understand you probably need a tested example however documentation is limited in this topic.

    Regards,

  • I see this topic is somewhat complicated. Ok, here's what I usually do to implement a Web Service:

    A simplified Web Service is something like this:

     

    // Description: Open ticket using Web Service
    // Parameters:
    // IM is the SCFile object with the IM record

    function OpenTicket(IM) {
    // Create Request Object
    var Request = new system.library.MySOAPlibrary.WebService();
    // Create Ticket Data Object
    var TicketData = new system.library.MySOAPlibrary.MessageRequest();
    // Set login data
    Request.user = "USER";
    Request.password = "PASSWORD"; // Set values for the request TicketData.data1.setValue("TEST"); TicketData.data2.setValue(IM.problem_type); TicketData.data3.setValue(IM.product_type); TicketData.data4.setValue(IM.severity.substring(0, 1)); // SOAP request to provider try { var result = Request.invoke(TicketData); if (!result.isFault())
    {
    var msgres = result._return.getValue();
    print("Result: " msgres);
    }
    // Error handling if (result.isFault())
    throw("ERROR SOAP: " result.faultstring.getValue());
    } catch (err) { print("ERROR: " err ); }
    }

     

    Now this is the basic structure of a standard SOAP Web Service. with basic authentification However one of our providers told us they set a cookie with the authentification data once we do the first request. So we have something like:

    var IM = new SCFile("incidents");
    var RC = IM.doSelect('incident.id="' INCIDENT_ID '"');
    if (RC == RC_SUCCESS)
    {
    AuthentificateWithProviderSOAPCall(); OpenTicket(IM);
    }

    The first call is a standard SOAP call with user and password somewhere.  The new OpenTicket function no longer specifies a user and password. The first call is supposed to send a cookie so the next message should be able to go through, but it doesn't. So I guess I need to "catch" the cookie on the Authentifiacion message, and then manulally set it on the OpenTicket? Anyone has experience with something like this.

    Thanks

     

  • I think, the important bits have been provided below:

    At first request with authentication, SM will respond by setting the JSESSIONID cookie. You can find this in the HTTP header (Set-Cookie). After that, your application can send this cookie in following request to SM in HTTP header (cookie).

    The trace below demonstrates that.

    Regarding your code: I think you can set the HTTP headers as properties to the request object. I would prefer request["<header name>"] syntax over request.<header name>, as there may be hyphens etc.

  • The SOAP libraries that SM generates do not deal with cookies, so instead of using doSOAPRequest (which is called by the invoke method that SM generates) shoud I use the doHTTPrequest and then and deal with all the little details in order to be able to get and set the cookies? That's the only way I know to capture the HTTP traffic...

    Thanks AFranke

  • I just checked the Programming Guide:

    Yes, doSOAPRequest() has no parameter for the header object - doHTTPRequest has.

    Actually the soap action in doSOAPRequest() is a header property - so this function is making the basic settings for the request. But I guess for keepalive you will need to do this yourself.

    Regarding example of using doHTTPRequest() and the Header object, you may want to have a look at ScriptLibrary smis_RestClient.

    However, I have not found a simple keepalive example.

     

    Help server references:

    Guides and reference > Programming Guide > JavaScript and Service Manager reference > Service Manager defined JavaScript objects > JavaScript object: Header

    Guides and reference > Programming Guide > JavaScript and Service Manager reference > List: JavaScript global methods > JavaScript global method: doSOAPRequest

    Guides and reference > Programming Guide > JavaScript and Service Manager reference > List: JavaScript global methods > JavaScript global method: doHTTPRequest

  • So that's what I suspected, if you have a SOAP Web Service that uses cookie authentification, you have to implementit by yourself using doHTTPRequest, which is a huge pain....