Tuesday, March 1, 2011

How not to name a configuration setting

Recently while looking over some FAST for SharePoint labs one of the exercises had you edit a property called:


The production setting for this is “false”, which will make the system do cleanup of a claims cache.

But reading the name and what it actually does is very hard due to using both the words “Allow”, “Non” and “TestingOnly”. You have a positive word, a negative word and a specific case where the property is valid, all in the same name.

The proper name for this should in my opinion be:


where the production value should be “true”. With a comment to explain why you would set this to false, e.g. in a test scenario.


  1. Hi Mikael... have you wondered how this cache works? In other words, what exactly is the communication from the SSA to the qrserver that we are disabling with this badly named switch?


  2. Hi Matt,
    It's a claims token used to validate the request between the SSA and the QR Proxy service on the FS4SP farm. The token is issued per request and is unique per user per search query. It is basically a security token to ensure no one can piggy back on your request credentials.

    By turning off "cleanup" the token will last more than 10 seconds which I believe is the expiration time for the tokens, allowing you to reuse it for testing purposes to impersonate a user doing queries.

    Instead of using this to execute queries manually via the QR server I developed http://fs4splogger.codeplex.com/ which re-executes the query with the captured token within the 10 seconds. This allows testing from the front-end or via SharePoint API's, which I find easier than using the QR server. But basically you achieve the same thing, you reuse a already issued token, to impersonate someone on a request.

  3. Thanks... does that mean the claim is sent as a cookie on the http request to the qr server? I'm just wondering how hard it was for them to retrofit this into the qrserver, which we know had only a very basic http server.

  4. Probably not that hard as it is sent as part of the query string on the GET request. Then the qr pipeline can easily pick it up.

  5. but when we call the qr server directly, we also pass it on the query string, and it doesn't go into the cache. I'm assuming there must be some _other_ communication from the SSA to the qr server that we are not replicating when we call the qr server directly. -Matt

  6. oh wait, I think I'm finally getting the idea... the fql_security parameter in the query is actually the identifier of a claim ticket, and the claim ticket has an expiration? I thought the fql_security parameter was simply an encoding of the user name, as it used to be in ESP.

  7. Hi,
    As I said above, communication between the SSA and FS4SP goes via the QR Proxy service. So you have: SSA -> QR Proxy -> QR Server.

    The QR Proxy is a WCF service which crafts the GET request to the QR Server and my guess is that it also creates the security token.

    And yes, the fql_security parameter is the claims ticket :)

  8. Sorry, had the parameter name all mixed up, it's qtf_securityfql. This powerpoint has a few enlightening slides

    It says that the claims come in to the QR Proxy service, which sends them to FSA Worker (aka SAM), which stores them and returns a "security claims token ID," and the QR Proxy adds the qtf_securityfql parameter with that token ID. I suspect the token ID does not have any meaning outside being a reference to a set of claims in the FSA Worker, and presumably that's the claims cache we've been talking about.

    1. I can verify that your assumptions are correct :)