For the Inline KeyCite Flags feature project, we're adding a parameter onto requests to the FullText endpoint of Document to indicate whether or not the user has purchased the feature (which is an ancillary charge). This leaves all the billing logic in the Website module. However, we noticed that for chunked docs, subsequent chunk requests go straight from the browser to the Document module.
I navigated to this document (125 S.Ct. 738 - U.S. v. Booker) in my browser and observed the following request in fiddler (using the normal forward proxy mode) for a subsequent chunk:
>
http://1.next.ci.westlaw.com/Document/v1/FullText/I3a84f1d79c9d11d991d0cc6b54f12d4d?clientId=ANDERSONBD1&chunkNumber=1&contextData=(sc.History*oc.UserEnteredCitation)&originalContext=UserEnteredCitation&originationContext=clientid&cacheScope=bce903a9a621049fb7de37a890ca3368I then took that fiddler request, slightly modified it by adding a parameter to the end, and reissued it in fiddler:
>
http://1.next.ci.westlaw.com/Document/v1/FullText/I3a84f1d79c9d11d991d0cc6b54f12d4d?clientId=ANDERSONBD1&chunkNumber=1&contextData=(sc.History*oc.UserEnteredCitation)&originalContext=UserEnteredCitation&originationContext=clientid&cacheScope=bce903a9a621049fb7de37a890ca3368**&inlineKeyCiteFlags=true**>
> response 200 - success (includes
> Inline KeyCite flags)
I then took the original request and changed the guid to Roe v Wade and reissued it in fiddler:
>
http://1.next.ci.westlaw.com/Document/v1/FullText/**I32a9810a9c2611d993e6d35cc61aab4a**?clientId=ANDERSONBD1&chunkNumber=1&contextData=(sc.History*oc.UserEnteredCitation)&originalContext=UserEnteredCitation&originationContext=clientid&cacheScope=bce903a9a621049fb7de37a890ca3368>
> response 403 - forbidden
What I'd like to be able to do is to make the second request above (for inline keycites) also return a 403. My guess, based on the very limited knowledge I have of what's going on, is that the guid is included in generating a hash that is then validated against the url to verify it hasn't been tinkered with. I'm guessing our new parameter (inlineKeyCiteFlags=true) is not included in that hash generation. Does anyone happen to know how/where that hash is generated?
All of the above requests use the same headers (below). I'm wondering if either the x-cobalt-pcid or the x-cobalt-rtid below is the hash consisting of certain parts of the url?
x-cobalt-documentContentCacheKey: WestlawNext|I3a84f1d79c9d11d991d0cc6b54f12d4d|||||||||0|False|{"HighlightPoints":null,"HighlightTerms":null,"SecondaryHighlightTerms":null}|False|||False|False|||True|L|False|Core|0|
x-cobalt-exectype: async
x-cobalt-pcid: 7f82b288ed5f410f85b23e67ea616ffa
x-cobalt-rtid: v1|47d85c13faeb49824a9be774dbe3d7e0c9804765232acb3eafd4b2df3859f8e9
x-cobalt-host: document.int.next.ci.westlaw.com
Accept: text/html, */*; q=0.01
X-Requested-With: XMLHttpRequest
Referer:
http://1.next.ci.westlaw.com/Document/I3a84f1d79c9d11d991d0cc6b54f12d4d/View/FullText.html?listSource=Foldering&originationContext=clientid&transitionType=MyResearchHistoryItem&contextData=(oc.UserEnteredCitation)&VR=3.0&RS=cblt1.0 Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Connection: Keep-Alive
DNT: 1
Host: 1.next.ci.westlaw.com
Cookie: Web_SessionId=az5ykzf1awrzh0gk5pf13acg; site=b; ig=ci_b_1; web_pm=10.220.24.37_9001; bhCookieSess=1; bhCookiePerm=1; bhResults=bhfx=11%2C7%2C700%2C224&bhfv=11&bhsh=1050&bhsw=1680; SessionStorage=%7B%22ReadingModeView%22%3A%22regular%22%2C%22IsSkipOutOfPlanChecked%22%3Afalse%2C%22Created%22%3A%2207/17/2013%2020%3A08%3A05%22%2C%22Client%22%3A%22ANDERSONBD1%22%2C%22ActiveReqs%22%3A6%2C%22ReqWindow%22%3A8%7D; Co_SessionToken=s8pL8HOCA-63C5Vp9i6yKSiA5HW-p7HR4p7GaoPoRYPqAf_-iTgw9htj32dnpEY8SHNDtp3-rJrV_m9wjdEj3hFBerM4yNe9SWlCN0VF9yiX0imFUSzqUMhqNZyiPJnF; RememberMe=%7B%22user%22%3A%22andersonbd1%22%2C%22pw%22%3A%22%25Au/oPm7PfEO-%22%7D; fol_pm=10.204.32.189_9001; BIGipServerci_apache_b=489282570.10787.0000; MUD=product=www
