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

Options
jefftucker
jefftucker Posts: 21 ✭
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: 21 ✭

    This being in the Context, I should say.

  • benken_parasoft
    benken_parasoft Posts: 1,364 ✭✭✭
    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: 21 ✭

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

    JT

  • jefftucker
    jefftucker Posts: 21 ✭

    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,364 ✭✭✭
    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: 21 ✭

    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,364 ✭✭✭
    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: 21 ✭

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

Categories