locked
Odd MEX request behaviour RRS feed

  • Question

  • Hi folks,

    I've written a PHP-based infocard STS, which Kim Cameron recently blogged about, and I'm now trying to smooth out some wrinkles I'm seeing working with CardSpace.

    The first time I use CardSpace to submit an infocard that my STS generates, I am granted access to my relying party, as expected.  The second time, the WS-MetadataExchange process fails.  Here's what I'm observing in my apache logs and in my own debugging output:

    - CardSpace sends an http POST to my mex.php script, along with a SOAP-enveloped mex request, as expected.  This is the case when it works.  I then see a SAML token issued, etc etc.  Yay.

    - Next in the logs, I see an http POST to my mex.php script, with the content-length set correctly (same length as the previous mex request), but there is no SOAP envelope, with no mex request included.  It's as if cardspace broke the connection instead of posting data.  First question: is this normal?  My mex responder currently gives a PHP error, for want of anything better to do.

    - Next in the logs, I see what I consider *very* bizarre, an http GET on my mex.php script from cardspace, with no http headers other than Host.  Second question: is this related to the answer to the first question?  My script gives an HTTP 400 can't-do-that response, which I see in the cardspace event log.

    If I kill the infocard.exe process and try again, it works once and then begins failing anew, as described.

    Any hints would be appreciated.

    Thanks,
      -Dave Coombs
       Carillon Information Security Inc.
       http://www.carillon.ca/

    Friday, July 13, 2007 8:35 PM

Answers

  • OK, I've figured it out.  Adding 1 to the Content-Length of my soap replies has made the problem go away.  It's granting me access to my relying party quite reliably now.

    Thanks, Matt, for your suggestions.  It did help.

    I still have another couple things to fix before I release a new version of the STS.  Hopefully soon...

      -Dave

    Tuesday, July 17, 2007 9:04 PM

All replies

  • I can't answer all your questions, unfortunately, but number 3 is normal behaviour - if the WS-MEX fails (the SOAP based POST), CardSpace drops down to a simple GET. You can just return the non-SOAP based MEX data here.

     

    As for why you get the empty SOAP POST, I can't say. I presume it's happening in response to another CardSpace request, i.e. you've double clicked on a card in the Identity Selector?

     

    Cheers

    Matt

    Friday, July 13, 2007 9:30 PM
  • Thanks Matt, much appreciated.  I'll modify my mex responder to return as much metadata as possible on GET.  I guess I could make it return the same stuff for an empty POST, although I still have no idea why I'm getting that.

    No, not double-clicking or anything like that.  It happens alarmingly consistently, too.

    Cheers,
      -Dave

    Monday, July 16, 2007 6:44 PM
  • Hey Matt,

    I've made my MEX responder deal with an HTTP-GET request now, and things are looking up.  We're getting a little farther.

    I'm still seeing failures, though.  The empty POST is still happening on mex, but now I'm also getting empty POSTs on the tokenservice!

    Again, the first time it works fine, but on subsequent attempts the POSTs are empty, for both mex and for the RST token request.

    Bizarre.

    Any hints from anybody would be appreciated!  Anybody seen anything like this before?

    Thanks,
      -Dave


    Tuesday, July 17, 2007 8:12 PM
  • OK, I've figured it out.  Adding 1 to the Content-Length of my soap replies has made the problem go away.  It's granting me access to my relying party quite reliably now.

    Thanks, Matt, for your suggestions.  It did help.

    I still have another couple things to fix before I release a new version of the STS.  Hopefully soon...

      -Dave

    Tuesday, July 17, 2007 9:04 PM