How do i playback a .m3u8 file encrypted by AES-128 - encryption

I'm trying to develop a custom receiver application. I used;
https://github.com/googlecast/CastMediaPlayerStreamingDRM
My server platform is IIS 7.5, and CORS requirements are satisfied.
In the .m3u8 file, there are two items, URI & initial vector.
EXT-X-KEY:METHOD=AES-128,URI="http://MY_SERVER_IP/FILE_NAME.key",IV=0x799a4490f82203e21ea413b1bf66bbf8
I put the license server URL on the custom receiver, but it does not work.
I get the messages are media player state : "underflow: true", media element state: "Stalled"
How do I solve it?
Thanks for reading my question.
Update #1
######### MEDIA ELEMENT LOAD START mpl.js:58
[ 38.556s] [goog.net.XhrIo] Opening Xhr [GET http://serverIP/.m3u8 -1] media_player.js:24
[ 38.572s] [goog.net.XhrIo] Will abort after 30000ms if incomplete, xhr2 false [GET http://serverIP.m3u8 -1] media_player.js:24
[ 38.578s] [goog.net.XhrIo] Sending request [GET http://serverIP.m3u8 -1] media_player.js:24
[ 38.619s] [goog.net.XhrIo] Request complete [GET http://serverIP.m3u8 200] media_player.js:24
[ 38.695s] [cast.player.core.QualityManager] 0: from undefined to 1308128 media_player.js:24
[ 38.701s] [cast.player.hls.Playlist] update: http://serverIP.m3u8 media_player.js:24
[ 38.709s] [goog.net.XhrIo] Opening Xhr [GET http://serverIP.m3u8 -1] media_player.js:24
[ 38.719s] [goog.net.XhrIo] Will abort after 30000ms if incomplete, xhr2 false [GET http://serverIP.m3u8 -1] media_player.js:24
[ 38.725s] [goog.net.XhrIo] Sending request [GET http://serverIP.m3u8 -1] media_player.js:24
[ 38.748s] [goog.net.XhrIo] Request complete [GET http://serverIP.m3u8 200] media_player.js:24
[ 38.776s] [cast.player.hls.Parser] unexpected EXT-X-KEY: state 3 media_player.js:24
### HOST ERROR - Fatal Error: code = 0 mpl.js:635
[ 38.785s] [cast.player.api.Player] unload media_player.js:24
######### MEDIA ELEMENT STALLED
When I try to play using VLC media player, it works.

The license file (key) must be served over https.

Related

Sending messages with attachments via Linkedin v2 messages API Fail

Sending any attachments via https://api.linkedin.com/v2/messages results in an empty message on the receiver end. It was working fine during the development and until a few months ago.
I followed the steps as mentioned in the doc here: Messages API.
1. Register upload
POST 'https://api.linkedin.com/v2/assets?action=registerUpload'
Headers: { 'x-li-format: json' ,'X-Restli-Protocol-Version: 2.0.0', 'Authorization': <AUTH TOKEN'>, 'Content-Type: application/json'}
Body:
{
"registerUploadRequest": {
"recipes": [
"urn:li:digitalmediaRecipe:messaging-attachment"
],
"owner": "urn:li:person:tVBKuamGQA",
"serviceRelationships": [
{
"identifier": "urn:li:userGeneratedContent",
"relationshipType": "OWNER"
}
],
"supportedUploadMechanism": [
"SYNCHRONOUS_UPLOAD"
]
}
}
2. Media upload
PUT 'https://api.linkedin.com/mediaUpload/D5606AQEyWs_FuSOhpQ/messaging-attachmentFile/0?ca=vector_messaging&cn=uploads_encrypted&m=AQLwVYaN1VD0FAAAAYZWQ5iaB1P3EvIEqybGym69KocRancNKS12YAhD2A&app=109663&sync=1&v=beta&ut=39P3TAA2AwmGE1'
Headers: Same as above
Body: Image in bytes format
3. Send message with the Attachment URN
POST 'https://api.linkedin.com/v2/messages'
Additionally, I was also able to verify that the status of the upload was successful.
Body:
{
"recipients": [
"urn:li:person:eDPvPwsUVS"
],
"subject": null,
"body": "Body3",
"messageType": "MEMBER_TO_MEMBER",
"attachments": [
"urn:li:digitalmediaAsset:D5606AQEyWs_FuSOhpQ"
]
}
4. Check status of the upload:
Additionally, I was also able to verify that the upload was successful with the status "AVAILABLE"
GET 'https://api.linkedin.com/v2/assets/D5606AQEyWs_FuSOhpQ'
All API calls shared here were successful, making it even more challenging to figure out why the attachments fail. Sending only texts works fine. Any insights/guidance on this issue will be greatly appreciated. It's currently blocking our major release.
I have gone through the assets api, images api documentations from LI, but that doesn't seem to be relevant for sending attachments via private message.
Assets API
Images API

Configuring retry policy for grpc request

I was trying to configure a retry policy from the client side for for some grpc services but it's not behaving the way I expect it to behave so I might be misunderstanding how retry policy works in grpc or there's a mistake in the policy. Here's the policy:
var retryPolicy = `{
"methodConfig": [{
"name": [{"service": "serviceA"}, {"service":"serviceB"}],
"timeout":"30.0s",
"waitForReady": true,
"retryPolicy": {
"MaxAttempts": 10,
"InitialBackoff": ".5s",
"MaxBackoff": "10s",
"BackoffMultiplier": 1.5,
"RetryableStatusCodes": [ "UNAVAILABLE", "UNKNOWN" ]
}
}]
}`
What I expected was that if the client's grpc request to a method defined in one the services(serviceA or serviceB) failed then I expect a retry and since waitForReady is true the client will block the call until a connection is available (or the call is canceled or times out) and will retry the call if it fails due to a transient error. But when I purposefully down the server which this request is going to. The client gets an Unavailable grpc status code and error is: Error while dialing dial tcp xx.xx.xx.xx:xxxx: i/o timeout but the client didn't get this error message 30 seconds later, instead received this error right away. Could the reason be because of how I'm giving the service names? Does it need the path of the file where the service is defined? For a bit more context, the grpc service is defined in another package which the client imports. Any help would be greatly appreciated.
Looking through the documentation, came across this link: https://github.com/grpc/grpc-proto/blob/master/grpc/service_config/service_config.proto and on line 72 it mentions
message Name {
string service = 1; // Required. Includes proto package name.
string method = 2;
}
I wasn't adding the proto package name when listing the services. So the retry policy should be:
var retryPolicy = `{
"methodConfig": [{
"name": [{"service": "pkgA.serviceA"}, {"service":"pkgB.serviceB"}],
"timeout":"30.0s",
"waitForReady": true,
"retryPolicy": {
"MaxAttempts": 10,
"InitialBackoff": ".5s",
"MaxBackoff": "10s",
"BackoffMultiplier": 1.5,
"RetryableStatusCodes": [ "UNAVAILABLE", "UNKNOWN" ]
}
}]
}`
where pkgA and pkgB are the proto package names.

The AWS Lambda returns "Error: connect ETIMEDOUT **.****.***.***:443"

I have to services, Admin Panel(Laravel) и Online Shop(Woocommerce). The relation between these to services was realized with AWS Lambda.
When I try to send an updating product request from my Admin panel to online shop, time to time the lambda couldn't connect to the Woocomerce API.
On time when the system is not updating the product, lambda returns the error "Error: connect ETIMEDOUT"
I originally thought that the Wordpress didn't have enought time for updating process. And decided to increase the lambda's timeout (60000 ms). But it didn't help. I still found the ETIMEDOUT errors in logs.
By the way, the time period between sending the updating request to woocommerce and showing an error is 2 min. If I right understand, the lambda had enough time for getting the answer from woocommerce.
Another strange thing. According the lambda's logs, on time when lambda got an error, the woocommerce API was available. It seems like something disconnects the internet on time when lambda is sending the request.
My question is, why lambda cannot send to Woocommerce API the request. Why it happens time to time?
P.S. Below I added the example of lambda's logs.
The log on starting sending the updating request.
2021-08-14T18:23:48.692Z b228455b-45a8-5cbf-8160-1cc INFO Inside edit Online List {
status: '1',
*********
is_delete: 0,
name: 'Omega Speedmaster Moonwatch Chronograph 42mm ',
price_on_request: 0,
on_sale: 0
}
The log with error.
2021-08-14T18:25:58.299Z b228455b-45a8-5cbf-8aae6 INFO WooCommerce editOnlineStock err::: { Error: connect ETIMEDOUT ***.****.***.***:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14)
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT',
syscall: 'connect',
address: '***.****.***.***',
port: 443,
config:
{ url:
'https://domain/wp-json/wc/v3/products/*****',
method: 'put',
params: {},
data:
'{"name":"Omega Speedmaster Moonwatch Chronograph 42mm ","type":"simple"***********',
headers:
{ Accept: 'application/json',
'Content-Type': 'application/json;charset=utf-8',
'User-Agent': 'WooCommerce REST API - JS Client/1.0.1',
'Content-Length': 681 },
auth:
{ username: 'ck_************',
password: 'cs_************' },
transformRequest: [ [Function: transformRequest] ],
transformResponse: [ [Function: transformResponse] ],
timeout: 60000,
adapter: [Function: httpAdapter],
responseType: 'json',
xsrfCookieName: 'XSRF-TOKEN',
xsrfHeaderName: 'X-XSRF-TOKEN',
****************************
Is your lambda associated with a VPC? If so, i) explore to see if the VPC has a route out to the internet with a NAT gateway/instance, ii) examine the VPC flow logs for errors.

issue with queue priority on RabbitMqBundle

I am trying to setup a priority queue. Without priority, it is working just fine but I need to prioritize messages.
I am using RabbitMqBundle 1.14 and rabbitmq-supervisor-bundle 3.1 with RabbitMQ 3.5.7 (Erlang 18.3)
Here is the config.yml :
old_sound_rabbit_mq:
connections:
default:
host: '127.0.0.1'
port: 5672
user: 'xxx'
password: 'xxx'
vhost: '/'
lazy: false
connection_timeout: 3
read_write_timeout: 3
# requires php-amqplib v2.4.1+ and PHP5.4+
keepalive: false
# requires php-amqplib v2.4.1+
heartbeat: 0
#requires php_sockets.dll
use_socket: true # default false
producers:
global:
connection: default
exchange_options: {name: 'global', type: direct}
queue_options:
name: global
consumers:
global:
connection: default
exchange_options: {name: 'global', type: direct}
queue_options: {name: 'global', arguments: {'x-max-priority': ['I', 10]} }
callback: rabbitmq_simu_service
And the message sent to queue :
$msg = array();
$msg['id'] = $id;
$msg['action'] = 'simu';
$additionalProperties = ['priority' => 4] ;
$routing_key = '';
$this->container->get('old_sound_rabbit_mq.global_producer')->publish(serialize($msg), $routing_key , $additionalProperties);
I get the following error when sending the message :
PRECONDITION_FAILED - inequivalent arg 'x-max-priority' for queue 'global' in vhost '/': received none but current is the value '10' of type 'signedint'
I also tried in the config.yml :
queue_options: {name: 'global', arguments: {'x-max-priority': 10} }
In this case, I got no error but messages are not consumed.
Does anyone know how to send priority message ?
The message you have received is the error message for what happens when you try to create a queue, but the queue already exists with different parameters. You must delete the queue first, then try running your program.
PRECONDITION_FAILED - inequivalent arg 'x-max-priority' for queue 'global' in vhost '/': received none but current is the value '10' of type 'signedint'
That message means that you have already created the global queue with a max priority of 10, but something else is trying to declare it with no priority. You must review your code for both your producer and consumer to ensure that if they declare this priority queue they use exactly the same x-max-priority argument.
NOTE: the RabbitMQ team monitors rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.

PactNet Provider test fails because of 404 when running the test

I have a consumer that has successfully created a pact file:
{
"consumer": {
"name": "CakeService"
},
"provider": {
"name": "CoolPersonService"
},
"interactions": [
{
"description": "A GET request to get a person who is cool",
"providerState": "There is a person who has IsCool set to 'true'6",
"request": {
"method": "get",
"path": "/CoolPersonService/persons/e674a2d0-57e6-471d-96dd-a91c0077283a",
"headers": {
"X-Requested-With": "XMLHttpRequest",
"CallerName": "Pact_Test#Local"
}
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json; charset=utf-8"
},
"body": {
"FirstName": "Some",
"LastName": "Name",
"IsCool": true
}
}
}
],
"metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}
}
The problem is the test for the provider. It gets a 404 for
/CoolPersonService/persons/e674a2d0-57e6-471d-96dd-a91c0077283a
but if I send a GET to that route using an HTTP client, I get a 200 response and the expected data is returned.
Here's the output from the test run:
Test Name: EnsureSomethingApiHonoursPactwithConsumer
Test Outcome: Failed
Result Message:
Test method PactTests.PactTests.EnsureSomethingApiHonoursPactwithConsumer threw exception:
PactNet.PactFailureException: Pact verification failed. See output for details.
If the output is empty please provide a custom config.Outputters (IOutput) for your test framework, as we couldn't write to the console.
Result StandardOutput:
[2018-07-13 10:59:05] INFO WEBrick 1.3.1
[2018-07-13 10:59:05] INFO ruby 2.2.2 (2015-04-13) [i386-mingw32]
..........++++++
..........++++++
[2018-07-13 10:59:07] INFO
[2018-07-13 10:59:07] INFO WEBrick::HTTPServer#start: pid=109760 port=9222
[2018-07-13 10:59:07] ERROR Errno::ECONNRESET: An existing connection was forcibly closed by the remote host.
C:/redacted/PactTests/bin/Debug/pact-win32/lib/ruby/lib/ruby/2.2.0/openssl/buffering.rb:61:in `sysread'
C:/redacted/PactTests/bin/Debug/pact-win32/lib/ruby/lib/ruby/2.2.0/openssl/buffering.rb:61:in `fill_rbuff'
C:/redacted/PactTests/bin/Debug/pact-win32/lib/ruby/lib/ruby/2.2.0/openssl/buffering.rb:301:in `eof?'
C:/redacted/PactTests/bin/Debug/pact-win32/lib/vendor/ruby/2.2.0/gems/webrick-1.3.1/lib/webrick/httpserver.rb:80:in `run'
C:/redacted/PactTests/bin/Debug/pact-win32/lib/vendor/ruby/2.2.0/gems/webrick-1.3.1/lib/webrick/server.rb:191:in `block in start_thread'
INFO: Reading pact at C:/redacted/PactTests/Pacts/cakeservice-coolpersonservice.json
Verifying a pact between CakeService and CoolPersonService
Given There is a person who has IsCool set to 'true'6
A GET request to get a person who is cool
with GET /CoolPersonService/persons/e674a2d0-57e6-471d-96dd-a91c0077283a
returns a response which
DEBUG: Setting up provider state 'There is a person who has IsCool set to 'true'6' for consumer 'CakeService' using provider state server at https://localhost/CoolPersonService/provider-states
I, [2018-07-13T10:59:11.805597 #102868] INFO -- request: POST https://localhost/CoolPersonService/provider-states
D, [2018-07-13T10:59:11.805597 #102868] DEBUG -- request: User-Agent: "Faraday v0.15.0"
Content-Type: "application/json"
I, [2018-07-13T10:59:23.352124 #102868] INFO -- response: Status 200
D, [2018-07-13T10:59:23.352625 #102868] DEBUG -- response: content-type: "application/json; charset=utf-8"
server: "redacted"
x-powered-by: "redacted"
date: "Fri, 13 Jul 2018 08:59:23 GMT"
connection: "close"
content-length: "84"
has status code 200 (FAILED - 1)
has a matching body (FAILED - 2)
includes headers
"Content-Type" which equals "application/json; charset=utf-8" (FAILED - 3)
Failures:
1) Verifying a pact between CakeService and CoolPersonService Given There is a person who has IsCool set to 'true'6 A GET request to get a person who is cool with GET /CoolPersonService/persons/e674a2d0-57e6-471d-96dd-a91c0077283a returns a response which has status code 200
Failure/Error: expect(response_status).to eql expected_response_status
expected: 200
got: 404
(compared using eql?)
2) Verifying a pact between CakeService and CoolPersonService Given There
is a person who has IsCool set to 'true'6 A GET request to get a person who is cool with GET /CoolPersonService/persons/e674a2d0-57e6-471d-96dd-a91c0077283a returns a response which has a matching body
>Failure/Error: expect(response_body).to match_term expected_response_body, diff_options, example
Encoding::UndefinedConversionError:
"\xC3" from ASCII-8BIT to UTF-8
3) Verifying a pact between CakeService and CoolPersonService Given There is a person who has IsCool set to 'true'6 A GET request to get a person who is cool with GET /CoolPersonService/persons/e674a2d0-57e6-471d-96dd-a91c0077283a returns a response which includes headers "Content-Type" which equals "application/json; charset=utf-8"
Failure/Error: expect(header_value).to match_header(name, expected_header_value)
Expected header "Content-Type" to equal "application/json; charset=utf-8", but was "text/html; charset=utf-8"
1 interaction, 1 failure
Failed interactions:
To re-run just this failing interaction, change the verify method to '.Verify(description: "A GET request to get a person who is cool", providerState: "There is a person who has IsCool set to 'true'6")'. Please do not check in this change! # A GET request to get a person who is cool given There is a person who has IsCool set to 'true'6
Here's the test method for the provider:
[TestMethod]
[TestCategory("Pact")]
public void EnsureSomethingApiHonoursPactwithConsumer()
{
const string serviceUri = "https://localhost/CoolPersonService";
var config = new PactVerifierConfig
{
Verbose = true
};
IPactVerifier pactVerifier = new PactVerifier(config);
pactVerifier
//.ProviderState($"{serviceUri}/provider-states")
.ProviderState($"{serviceUri}/provider-states")
.ServiceProvider("CoolPersonService", serviceUri)
.HonoursPactWith("CakeService")
.PactUri(#"C:\repos\Pact\API_CoolPersonService\PactTests\Pacts\cakeservice-coolpersonservice.json")
.Verify();
}
If you do a GET to a resource, and you get a 404, to me it sounds like the expected data is not present on the server - and that implies that the provider state has not been set up correctly.
Please read about provider states here https://docs.pact.io/getting-started/provider-states and here https://docs.pact.io/implementation-guides/ruby/provider-states#non-ruby-applications
If you do a POST to the same route and receive the response you expected from a GET, it may be that you have just created a new resource, and it is returning the body of the newly created resource.
I see that you are also having some encoding issues (Encoding::UndefinedConversionError: "\xC3" from ASCII-8BIT to UTF-8) I believe this has been fixed in the latest version of the underlying library (called the "pact standalone") so please ensure you have the latest version of pact-net. If you already do have the latest version of pact-net, then please raise an issue for the standalone to be upgraded.
For those still stumped by the issue, the "\xC3" from ASCII-8BIT to UTF-8 error also happens because the response by your provider couldn't be encoded e.g. your provider returns a 500 with a text/html response.

Resources