WCF Streaming Service/Multiple GET requests from Media Player - wcf

I've run into a problem with a WCF streaming service. That problem is due to Windows Media Player submitting multiple GET statements when you tell it to load the URL. Simply put, the multiple GET statements cause the entire stream to be requested more than once.
I'm guessing each one of these requests has a specific task, such as possibly requesting metadata, media type, and so on. The problem is I cannot seem to find any specification as for these GET requests on the web, nor can I make much sense of the packet captured "GET" requests to determine what exactly they are expecting back.
The first GET statement (length 294):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: Windows-Media-Player/12.0.7601.17514\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Second (500~ packets later) GET statement (length 364):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Cache-Control: no-cache\r\n
Connection: Keep-Alive\r\n
Pragma: getIfoFileURI.dlna.org\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514\r\n
GetContentFeatures.DLNA.ORG: 1\r\n
Host: serverName:port\r\n
Third (130~ packets later) GET statement (length 324):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514\r\n
Icy-Metadata: 1\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Fourth (200~ packets later) GET statement (length 687):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.0.7601.17514\r\n
Host: serverName\r\n
X-Accept-Authentication: Negotiate, NTLM, Digest, Basic\r\n
Pragma: version11-enabled=1\r\n
Pragma:
no-cache,rate=1.000,stream-time=0,stream-offset=0:0,packet-num=4294967295,max-duration=0\r\n
Pragma: packet-pair-experiment=1\r\n
Pragma: pipeline-experiment=1\r\n
Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch,
com.microsoft.wm.predstrm, com.microsoft.wm.startupprofile\r\n
Pragma: xClientGUID={3300AD50-2C39-46c0-AE0A-1623CEEA9A7E}\r\n
Accept-Language: en-US, *;q=0.1\r\n
Fifth (40~ packets later) GET statement (length 294):
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.0.7601.17514 WMFSDK/12.0\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Sixth (200~ packets later) GET statement:
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.0.7601.17514 WMFSDK/12.0\r\n
Accept-Encoding: gzip, deflate\r\n
Host: serverName:port\r\n
Connection: Keep-Alive\r\n
Seventh/LAST (70~ packets later) GET statement:
GET
/Service.svc/GetVideo/?id=123&authCode=37566528-DA87-4293-92F7-8BF791461729
HTTP/1.1\r\n
Cache-Control: no-cache\r\n
Connection: Keep-Alive\r\n
Pragma: getIfoFileURI.dlna.org\r\n
Accept: /\r\n
User-Agent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514\r\n
GetContentFeatures.DLNA.ORG: 1\r\n
Host: serverName:port\r\n
Has anyone run into this before or have any reference to what each of these GET requests is expecting in response? They can't possibly all want a new STREAM and WCF appears to not handle them without calling for a new stream.

Put this in htaccess
SetEnvIf User-Agent NSPlayer BAD_BOT
Order Allow,Deny
Allow from all
Deny from env=BAD_BOT
Please look at this post, for details:
http://www.webhostingtalk.com/showthread.php?t=637335

Related

here.com API oAuth credentials

I am testing the here.com location REST API. I have setup REST oAuth credentials in the developer portal and have successfully requested an oAuth token via Postman. When I try to use the token in the fuel prices API, I receive the error:
"These credentials do not authorize access"
oAuth POST request:
Authorization: OAuth oauth_consumer_key="wD7h-u8jE03c0jRu2m4XBQ",oauth_signature_method="HMAC-SHA256",oauth_timestamp="1600812281",oauth_nonce="npygZT9FJ9f",oauth_version="1.0",oauth_signature="fM6AsYnp9jKHlY6ESyKwUwqIHQik4ad6spUeiWAh2ag%3D"
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: 169bc9d1-5ef6-46e6-aab8-d0d11d048d15
Host: account.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Request Body
Response Headers
Date: Tue, 22 Sep 2020 22:04:42 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 911
Connection: keep-alive
Pragma: no-cache
X-Request-ID: REQ-b62ce9c9-eddd-4c03-8e67-186a56c031b1
Cache-Control: no-store
X-Frame-Options: DENY
X-Response-Time: 53
X-Correlation-ID: e0c4b375-8fed-4b70-be56-2d78c6f37e18
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
X-Permitted-Cross-Domain-Policies: master-only
Response Body
{"access_token":"eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw","token_type":"bearer","expires_in":86399}
Get request to fuel REST API
GET https://fuel-v2.cc.ls.api.here.com/fuel/stations.json?prox=36.0029435,%20-78.9059841&fueltype=1
Request Headers
Authorization: Bearer eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: d5d3944f-4c5c-44ef-8eb4-0202a4d669c0
Host: fuel-v2.cc.ls.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response Headers
Content-Encoding: gzip
Content-Type: application/json
Date: Tue, 22 Sep 2020 22:11:15 GMT
Server: nginx-clojure
Vary: Accept-Encoding,Origin
X-HERE-RESPONSE-TIME: 0
Content-Length: 99
Connection: keep-alive
Response Body
{"Type":"Forbidden","Message":["These credentials do not authorize access"]}
Unfortunately, currently the Freemium plan doesn't have an access to Connected vehicle services https://developer.here.com/documentation#cvs
On https://developer.here.com/documentation/fuel-prices/dev_guide/topics/credentials.html you can see:
There are two kinds of credentials:
Development credentials - these credentials are for evaluation and
development. To obtain your development credentials, contact your
customer/sales representative and sign the appropriate evaluation
agreements.
Production credentials - these credentials are for commercial
deployment. To obtain your commercial credentials, sign the
appropriate commercial agreements. You must have completed all
testing, be ready for deployment and have signed a commercial
agreement before you apply for production credentials.
You can also read this Knowledge Base What other HERE Location Services limits apply to my Freemium or Pro plan? - there the information about Connected vehicle services will be added later.

how to use httpwebrequest to login to site in vb.net

i want to login to site with my account but using vb.net "httpwebrequest"
this is the header :
http://www.alexasurfing.com/login?task=user.login
POST /login?task=user.login HTTP/1.1
Host: www.alexasurfing.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.alexasurfing.com/login
Cookie: __cfduid=d09a17b9b5acf54646546541471462027; refid=14786;
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 159
username=GMAL%40gmail.com&password=PASWW&remember=yes
HTTP/1.1 303 See other
Date: Wed, 17 Aug 2016 19:30:48 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.17
Location: /dashboard/profile
Server: cloudflare-nginx
i dont know how to use httpwebrequest to login to the site with my account ?
See the example here:
HTTP request with post
your post data is: username=GMAL%40gmail.com&password=PASWW&remember=yes
Note: You are sending plain text password over http. If there's an https option you should use that.

How Shockwave player generates HTTP POST request?

I am intercepting HTTP request/response from an Adobe Shockwave-based web music player application using Chrome Dev tools. When I click the Play button on music player, HTTP request headers like following are raised:
POST /some_url HTTP/1.1
Host: something.com
Connection: keep-alive
Content-Length: 103
Origin: http://something.com
X-Requested-With: ShockwaveFlash/22
User-Agent: Mozilla
Content-Type: application/x-www-form-urlencoded
Accept: */*
Referer: http://something.com/player.swf
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
And Form data looks like following:
param1=561a0d9452069h76fhg46h67a599e8gy34nlj=
param2=something
Now, is there any way to know from where this param1=561a0d9452069h76fhg46h67a599e8gy34nlj= form data came from and how it is generated? If it's some kind of encrypted string or a token, how this is done?
Thank you for your answers
The HTTP request would have come from a URLRequest in ActionScript, which passes the data in key/value pairs. You could have a look at using SWFWire Inspector to decompile the code.

Connection issues from certain devices

Can't connect from device using custom authenticator and ChallengeHandler.
This is from Worklight 6.1.0.2 from an iPod Touch device. On the worklight server, we see this in the Stack Trace.
klight.console.controllers.UsersController from Application javax.ws.rs.core.Application
[10/8/14 15:20:04:170 CDT] 0000001c com.worklight.core.auth.impl.LoginContext E FWLSE0059E: Login into realm 'NullLoginModule' failed. Invalid gadget request format: /WorkExecution/iphone/my_custom_auth_request_urlnull. Unknown handler path: my_custom_auth_request_url. [project AnywhereWorkManagement]
com.worklight.gadgets.GadgetRuntimeException: Invalid gadget request format: /WorkExecution/iphone/my_custom_auth_request_urlnull. Unknown handler path: my_custom_auth_request_url
at com.worklight.gadgets.api.GadgetAP
Our challenge handler submits our Authentication information using this Javascript call:
challengeHandler.submitLoginForm(challengeHandler.getAuthURL(), loginOptions, l
Where getAuthURL returns the string "/my_custom_auth_request."
Strangely, other devices using the same application and worklight server are allowed to login successfully. Another weird datapoint is that if we popup the Worklight Settings panel on this iPod Touch device, and update the Worklight server information, the worklight login then seems to succeed.
Wireshark log from the failed connection:
POST /AnywhereWorkManagement/apps/services/api/WorkExecution/iphone/login HTTP/1.1
Host: mobilenext1.tivlab.austin.ibm.com
Accept-Language: en_US
User-Agent: Mozilla/5.0 (iPod touch; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 (367413328)/Worklight/6.1.0.02.20141006-1624
Content-Length: 71
x-wl-platform-version: 6.1.0.02.20141006-1624
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-wl-app-version: 7.5.1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Connection: keep-alive
x-wl-native-version: 1475155033
x-wl-device-id: 36CDA8F2-F4E9-49D8-8CBB-A250FDC3B8FA
Cookie: WL_PERSISTENT_COOKIE=ac72a920-b614-423d-8347-e4b5c96a4a1b
Origin: file://
Accept-Encoding: gzip, deflate
realm=CustomAuthenticationRealm&isAjaxRequest=true&x=0.7606244247872382HTTP/1.1 503 Service Unavailable
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Content-Language: en-US
Content-Length: 0
Connection: Close
Date: Fri, 10 Oct 2014 14:32:15 GMT
Then after updating the Custom URL to remove the trailing slash, and relogging in, here's the wireshark log from the successful login:
POST /AnywhereWorkManagement/apps/services/api/WorkExecution/iphone/query HTTP/1.1
Host: mobilenext1.tivlab.austin.ibm.com
Accept-Language: en_US
User-Agent: Mozilla/5.0 (iPod touch; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 (384405120)/Worklight/6.1.0.02.20141006-1624
Accept-Encoding: gzip, deflate
Content-Length: 210
x-wl-platform-version: 6.1.0.02.20141006-1624
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-wl-app-version: 7.5.1.1
Accept: text/javascript, text/html, application/xml, text/xml, */*
Connection: keep-alive
x-wl-native-version: 1475155033
x-wl-device-id: 36CDA8F2-F4E9-49D8-8CBB-A250FDC3B8FA
Cookie: WL_PERSISTENT_COOKIE=0983cfc8-8526-48c9-99cb-72659cb934b4; JSESSIONID=0000wSxsNgF79M62_UJTNmXKKYC:2e8ee48e-dec4-4c69-b8b4-ad37f839f1be
Origin: file://
WL-Instance-Id: okur33g93p35c9j7rvpk1r9g5j
adapter=OSLCGenericAdapter&procedure=getProperties&compressResponse&parameters=%5B%7B%22propertyNames%22%3A%5B%22si.auth.type%22%5D%7D%5D&__wl_deviceCtx=Ar1Cjm4_mo9jpBAA&isAjaxRequest=true&x=0.33572526928037405HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Content-Type: application/json; charset=UTF-8
Cache-Control: no-cache, no-store, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Content-Length: 93
Date: Fri, 10 Oct 2014 14:43:15 GMT
/*-secure-
{"isSuccessful":true,"responseID":"1516","properties":{"si.auth.type":"maximo"}}*/POST /AnywhereWorkManagement/apps/services/api/WorkExecution/iphone/my_custom_auth_request_url HTTP/1.1
Host: mobilenext1.tivlab.austin.ibm.com
Accept-Language: en_US
User-Agent: Mozilla/5.0 (iPod touch; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 (384405120)/Worklight/6.1.0.02.20141006-1624
X-Requested-With: XMLHttpRequest
Accept: text/javascript, text/html, application/xml, text/xml, */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
x-wl-app-version: 7.5.1.1
Connection: keep-alive
Cookie: WL_PERSISTENT_COOKIE=0983cfc8-8526-48c9-99cb-72659cb934b4; JSESSIONID=0000wSxsNgF79M62_UJTNmXKKYC:2e8ee48e-dec4-4c69-b8b4-ad37f839f1be
x-wl-device-id: 36CDA8F2-F4E9-49D8-8CBB-A250FDC3B8FA
Content-Length: 62
Origin: file://
Accept-Encoding: gzip, deflate
username=wilson&password=wilson&authType=maximo&langcode=en-USHTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
P3P: policyref="/w3c/p3p.xml", CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Content-Type: application/json; charset=UTF-8
Cache-Control: no-cache, must-revalidate
Content-Language: en-US
Transfer-Encoding: chunked
Date: Fri, 10 Oct 2014 14:43:15 GMT
19
{"authStatus":"complete"}
0
I found this in the server logs to correspond with that 503 error from worklight server (I can reproduce by POSTing the same login URL). However in our Worklight Console, there is only one version of each application listed for iphone.
[10/10/14 10:37:54:063 CDT] 00000485 com.worklight.gadgets.serving.GadgetAPIServlet E FWLSE0020E: Ajax request exception: The environment 'iphone' supports multiple versions, therefore you must request it with a version parameter. [project AnywhereWorkManagement]
[10/10/14 10:37:54:066 CDT] 00000485 com.worklight.gadgets.serving.GadgetAPIServlet E FWLSE0117E: Error code: 1, error description: INTERNAL_ERROR, error message: FWLSE0069E: An internal error occurred during gadget request [project AnywhereWorkManagement]The environment 'iphone' supports multiple versions, therefore you must request it with a version parameter., User Identity {wl_authenticityRealm=null, CustomAuthenticationRealm=null, wl_remoteDisableRealm=null, wl_antiXSRFRealm=null, wl_deviceAutoProvisioningRealm=null, wl_deviceNoProvisioningRealm=null, wl_anonymousUserRealm=null}. [project AnywhereWorkManagement]
Scott,
The workaround is to remove the trailing slash from the Server URL.
For a permanent fix I suggest that you will open a PMR so that the development team could investigate the issue closely.
When doing so, please provide a reproducible test case because the flow does work fine, but seems to not work in yours, so need to better understand where exactly it fails. Be sure to provide this question in the description.
It could be that you are altering the URL somewhere in your challenge handler?

First request from BizTalk WCF-Custom adapter not pre-authenticated

The first request (or batch of requests) I send from a WCF-Custom adapter using the wsHttpBinding (also tried basicHttp) does not include the Authorization Header.
Request 1 Headers
POST https://axis2service.com/HttpSoap12Endpoint/ HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Host: axis2service.com
Content-Length: 556
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
The service returns a 401 to which I respond with the below.
Request 2 Headers
POST https://axis2service.com/HttpSoap12Endpoint/ HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Authorization: Basic XXXXXX
Host: axis2service.com
Content-Length: 556
Expect: 100-continue
Accept-Encoding: gzip, deflate
To which the axis2 on apache service responds with a 504 and Connection: close
This seems to be a known issue, how can I make request 1 include the Authorization header every time?
Note: The request 1 headers only get sent on the first request after a Host Instance restart. All subsequent requests from the adapter use the request 2 headers therefore bypassing the handshake stage.