Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Update Cookie Data using SOAtest Extension Tool

jefftucker
jefftucker Posts: 26 ✭
in SOAtest

Would it be possible to use an extension tool to update the "domain" attribute of an HTTP cookie in a test? As an example, if the cookie was set with a Domain value of "foo.bar.com" is there a way to update that to make the Domain value "foo.bar.net" ?

Comments

  • jefftucker
    jefftucker Posts: 26 ✭

    This being in the Context, I should say.

  • benken_parasoft
    benken_parasoft Posts: 1,374 ✭✭✭
    edited May 1

    No, not really. SOAtest Client tools handle HTTP cookies similar to a web browser. If your application set a cookie for the wrong domain then I'd try to address that issue directly.

    If your application is accessed behind a reverse proxy server then that server may need to be configured to re-write the HTTP cookies returned by the application. For example, nginx has a proxy_cookie_domain directive.

  • jefftucker
    jefftucker Posts: 26 ✭

    Thanks. Good info. I'll snag the value and set it in a new cookie with the correct domain name.

    JT

  • jefftucker
    jefftucker Posts: 26 ✭

    I was looking into modifying the response (either header or body) of a REST client. Is that possible in SOAtest? I have attached an Extension Tool but it doesn't seem to have any effect on the response. Thanks JT

  • benken_parasoft
    benken_parasoft Posts: 1,374 ✭✭✭
    edited May 2

    The REST Client has "Response Transport Header" and "Response Traffic" outputs. These provide access to the header and body of the HTTP response payload that the REST Client already received. Any "Set-Cookie" response headers are processed and stored internally as the response was being read, before running output tools.

    If your application is putting the wrong domain in the cookie then this wouldn't just impact SOAtest but any other client. I really recommend that you correct your application deployment so that it uses the correct host name. Otherwise, you would have to use something like a reverse proxy server that can re-write HTTP response headers before they are returned to the client. If your application is already deployed behind something like a reverse proxy or load balancer then those would need to be configured to re-write the domain in the Set-Cookie headers.

  • jefftucker
    jefftucker Posts: 26 ✭

    Thanks for the confirmation. The cookie, technically, is not being set incorrectly.... and it's nothing I have the ability to change. The issue is that the domain has a FQDN with a "leading dot" which (IMO is not the way to go) causes older (non-RFC 6265-compliant) browsers to not match. Seems that with RFC 6265 the leading dot can/should be ignored. I don't think the embedded REST client in SOAtest does that. That's just what I have seen. I think I can just set up a hit to a responder to echo back the proper cookie setter for my use case. Thanks again for the input. I really appreciate it. I really like how extensible you've made SOAtest and Virtualize. JT

  • benken_parasoft
    benken_parasoft Posts: 1,374 ✭✭✭
    edited May 2

    From RFC 6265 section 4.1.2.3:

    Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted

    Doing something "not permitted" would be the fault of the application but not ignoring the leading dot would be the fault of the client. Offhand, it looks like SOAtest does an "ends-with" check on the domain. So, if the cookie was set for ".example.com" then it would match "www.example.com" but probably not "example.com". SOAtest could be improved to ignore the leading dot but this is definitely a funny case.

  • jefftucker
    jefftucker Posts: 26 ✭

    IMO (old school) if it starts with a dot it should only match subdomains.

  • jefftucker
    jefftucker Posts: 26 ✭

    Hi benken_parasoft... any chance this has been addressed in any patches? I believe we submitted a request awhile back. It's definitely impacting things for me. The leading dot is valid, and I doubt it is something that will change.

  • jefftucker
    jefftucker Posts: 26 ✭
    edited August 20

    .

  • jefftucker
    jefftucker Posts: 26 ✭

    is there a way I can add this configuration to my existing SOAtest?

    https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/client/config/CookieSpecs.html#STANDARD

  • jefftucker
    jefftucker Posts: 26 ✭

    Or is there a way I can specify HTTP Client 5.x.x, which appears to be in the patched 2024 distribution?

  • benken_parasoft
    benken_parasoft Posts: 1,374 ✭✭✭
    edited August 21

    The leading dot is valid, and I doubt it is something that will change.

    Earlier you stated "The cookie, technically, is not being set incorrectly."
    I also referenced the RFC which confirms it is "not permitted".
    So, it looks like a genuine defect in the application-under-test.

    Even though the RFC states this is "not permitted" it also says in the same sentence that the client should ignore the dot if the application were to do such a thing. SOAtest could be enhanced to ignore the leading dot.

    any chance this has been addressed in any patches?

    There is indeed a request being tracked for this but if there are questions then you'll need raise them with your Parasoft account representative. I can't answer such things on the forum.

    Or is there a way I can specify HTTP Client 5.x.x, which appears to be in the patched 2024 distribution?

    The REST Client uses its own HTTP client implementation and not this library.

    I'm not aware of any workaround other than what I suggested earlier, where you could use a reverse proxy server to re-write the Domain attribute in any Set-Cookie headers.

  • jefftucker
    jefftucker Posts: 26 ✭

    Thanks for the details. We discussed with our Parasoft support team today.

Categories