Shaka Player - Get Widevine License URL - video.js

I want to play DASH file in Shaka Player with help of Widevine DRM.
And for this, i want to make XHR request to get Widevine License URL and then give that license URL to Shaka Player so it can play my DASH .mpd file and i do not know how to do that, So can anybody help me to solve this ?
For example::
My Dash File - https://example.com/7844-6093f36b051c9/manifest.mpd
URL to get Widevine DRM License URL - https://example/v1/drm/content/ticket/?streamId=47072
Response that I'm getting from above link is as below & In that response I'm getting actual Widevine License URL which i need to apply to Shaka Player..
And When this, licence_server_url (From Above Response, I'm getting this URL) is called from player, I'm getting response like this
So I have Widevine DRM License URL but I don't know how to use this in such way with Shaka Player so that my Dash .mpd file can star playing..
So can anybody please help to solve this.. ?
It would be really nice and awesome if anybody can solve my issue and help me..
Thank you in advance. :)

To configure Widevine license servers URL in Shaka Player, the following config is used in the player API:
player.configure({
drm: {
servers: {
'com.widevine.alpha': 'https://foo.bar/drm/widevine',
'com.microsoft.playready': 'https://foo.bar/drm/playready'
}
}
});
Morte info here (at the time of writing): https://shaka-player-demo.appspot.com/docs/api/tutorial-drm-config.html
In case it is not clear from the Shaka documentation, for WIdevine license requests the request must be made by the player and the widevine client on the device/browser. The license request and response are signed by the widevine license client and the widevine server respectively and cannot be read by any other entity, even the OS on the client (unless the DRM has been compromised). The widevine client will supply the decrypted license to the browser CDM (Content Decryption Module) and it will use it to decrypt and (usually) send the content directly to the display.

Related

idpiframe_initialization_failed with People Api

I am testing out the People Api, i started with the Browser quick start from google
I have followed all the instructions shown on the quick start.
I also added my localhost url to Authorized origins section on google developer console. I made sure i have the correct api key and client ID.
When i access the app's url http://0.0.0.0:8081/ , the page sends back below error
People API Quickstart
{
"error": "idpiframe_initialization_failed",
"details": "Not a valid origin for the client: http://0.0.0.0:8000 has not been whitelisted for client ID 555307262665-8a97q8pl4etkjh98nvsqnn9hu9ah68bv.apps.googleusercontent.com. Please go to https://console.developers.google.com/ and whitelist this origin for your project's client ID."
}
I've read online about the issue and most people seemed to have sorted the issue by clearing browser cache.
I've cleared browser cache and enabled see cookies and site data for
accounts.google.com on the browser, but that doesn't seem to help, i still get the error.
Is there anything am missing ?

After using Navigator.geolocation API on IE 11, How do we prevent HTTP POST to inference.location.live.net?

We have started using Navigator.geolocation API on IE 11 with HTML 5 and started seeing a HTTP POST call is being made from no where to the URL "https://inference.location.live.net/inferenceservice/v21/Pox/GetLocationUsingFingerprint", I need help in understanding that which API fires this particular call (IE 11 / geolocation API) and how do we not send request with geolocation functionality intact.
Any help would be greatly appreciated.
The HTTP POST call cannot be removed as it's performing the actual Geolocation from available network information (IP address and nearby WiFi networks)
Chrome and Firefox also submit data to an HTTP endpoint. In fact, both use the same service: Google Location Services
From Google Chrome Help:
If you let Chrome share your location with a site, Chrome sends information to Google Location Services to get an estimate of where you are. Chrome can then share that info with the site that wants your location.
From Firefox Location-Aware Browsing:
By default, Firefox uses Google Location Services to determine your location by sending:
your computer’s IP address,
information about the nearby wireless access points, and
a random client identifier, which is assigned by Google, that expires every 2 weeks

Unable to subscribe to Pushpad Safari notifications

I'm using the Pushpad.xyz library and got my Chrome notifications to work. On Firefox, I call pushpad('unsupported', callbackFunction) and the callbackFunction successfully executes (another bug that I am figuring out separately since Firefox should be supported). However, I am unable to get Safari notifications to work. I entered my Apple developer's certificates as requested in https://pushpad.xyz/docs/pushpad_pro_requirements.
pushpad('init', projectID);
pushpad('uid', signature);
pushpad('subscribe', function(isSubscribed) { alert(isSubscribed); });
pushpad('unsupported', function() { alert('Unsupported browser'); });
On Safari, I don't get the callback to unsupported and the docs say that Safari is supported. Why does it say that the user (me) has blocked notifications for this website? The callback to "status" always returns false. Is there a way to verify that I set up my Apple certificate correctly? Thanks!
The problem with Safari is definitely related to the download of the push package and its signature.
When pushpad('subscribe') is invoked Safari tries to download a "push package" from Pushpad servers and verifies its integrity and signature. If an error occurs (e.g. the signature verification fails) then the user is not even asked for permission and permission is not granted (its value remains default).
So you see that strange message that says that the user has not granted permission. Actually in your case it's not the user who is blocking the notifications: it's Safari who refuses to subscribe to push notifications because the push package is invalid.
Please try to generate again and fix the APNS private key and APNS certificate in your sender's settings on Pushpad. This should solve the issue.
Make sure to follow exactly the steps described here for APNS:
https://pushpad.xyz/docs/pushpad_pro_requirements
If you are testing your website locally make sure to follow the instructions as described in the "Working Locally" section:
pass the hostname option to init
make sure that the address is exactly http://localhost (if you use for example http://127.0.0.1 Safari won't work locally)

Phone and backend connection, how to minimize hacking

I was reading some topics about security and how hackers can look at the request you send to the backend to figure out how your system works but I did not find any good solution to avoid this.
So I was wondering what would you do in your app (here an iphone app) to make sure that hackers cannot see the content of the request your sending to the backend.
example http://myserver.com/api.php/login&pwd=test&username=pwd,
how to hide this so that no one can see the content.
I was thinking of different solutions:
1) encrypt the pwd and the username (not ideal as hacker can still see the post function of the server you are sending the request to)
2) use SSL request (I think this is only interesting to secure the connection to the server, meaning if the hacker is using his phone to connect to the server he should be able to see the request he is sending and so see the full URL)
3) change my backend so that all the request are sent to the same post function with an encrypted message. Finally the backend would decrypt and dispatch the message to the right function. This could work as the hacker would only see the url I am sending my request but would not have any information on what I am sending.
example: http://myserver.com/api.php/receiver&message=415gre6168sg4rg4e61g6r8g
"415gre6168sg4rg4e61g6r8g" could be decrypted as:
"login#pwd#username" and so I would be able to send this to the right function
But I am sure some of you have encounter similar issues and have better suggestions, would be interested to see what you would do,
Thanks
Any encryption you add is an extra effort for the hackers.
But in terms of what concerns to Apple use SSL connection should be enought based on iOS and the new IT - Security.
You can read more about the security polices used/recommended by Apple on iOS Security Guide

SOAP API: SiteTraversal WSDL return 404

I'm trying to retrieve all the available sites from the Yodlee API.
As I did for User Registration or Cobrand Login, I tried to obtain the list of available method on the WSDL endPoint.
Basically, I pass this to my yodlee url + / services url :
SiteTraversalService?wsdl
But all I receive is a 404.
Wasabi::Resolver::HTTPError: Error: 404
Does anyone has an idea?
Thanks,
Yodlee Service URL 404s generally happen because the the URL in fact is incorrect.
This can happen because of several reasons.
Either the URL is invalid
The Version was not specified in the Service Url (and the functionality you requested is not available in the fail-over API version).
To check if your URL is valid/invalid you need to enable tracing so you can see the exact request url that went out.
If you're on Windows you may find Fiddler to be very useful for this. (You will need to enable the requirements for sniffing/decrypting SSL Traffic). For other platforms the SDK Guide has some other alternatives.
Once you've ensured that the URL is valid the next step is making sure you're specifying the version.
Newer API functionality is not available in older API Versions. You specify the Version in your Service Url URL which determines the functionality that is available to you. Yodlee versions are appended to the Service Page Url in the form of _Major_Minor (12.0 and 11.1) would be _12_0 or _11_1
Example:
new EndpointAddress(BaseServiceUrl + Name_TransactionDataService + ServiceVersionPrefix)
where
BaseServiceUrl is your base Yodlee url (provided by your rep or Yodlee Dev Center)
Name_TransactionDataServices is say "TransactionDataService"
and VersionPrefix would be your version/sub version in the format of "_12_0" or "_11_1" (12.0 or 11.1).
So your url should look/resemble the following:
https://yodleedomain/yodsoap/services/TransactionDataServices_12_0
(I do not append the ?WSDL to the url).
If you want to test the connectivity to the Yodlee service, do the following --
Invoke -- https://yodleedomain:port/yodsoap/services/listservices