When will it be posible to exchange any kind of data via P2P with WebRTC?
I'm thinking about making a P2P bittorrent software, not to stream audio/video.
Thanks
There are some JS libraries: PeerJS and BoneValue for P2P data exchanging using WebRTC.
If you want to make a BitTorrent-like JS app for sending files, be aware that there are some already - BtAppJS, ShareFest, ShareIt, RTC-P2P, and P2P-Share.
This will available in Chrome using the DataChannel: http://webrtc-demos.appspot.com/html/dc1.html
You can see an overview in this talk from Google I/O: http://www.youtube.com/watch?v=E8C8ouiXHHk&t=24m30s
I have not been able to establish a data connection in Chrome 21 or 22 (Canary), next step is to try compiling for myself.
P2P bittorrent software based on WebRTC already exists. It's called WebTorrent (source).
WebRTC that doesn't stream audio/video but arbitrary data is called RTCDataChannel: https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel
But you are late - WebTorrent already exists.
WebTorrent client: https://github.com/webtorrent/webtorrent
WebTorrent tracker implementation: https://github.com/Novage/wt-tracker
Hybrid BitTorrent\WebTorrent tracker: https://github.com/webtorrent/bittorrent-tracker
Related
I would like to know if MSAL can be used with Identity providers other than Microsoft products. If yes, how.
I checked the MSAL documentetion but it is not straightforward in this question.
What I would like to do is to authenticate to Google and OneLogin (and possibly others later) using MSAL, but I don't know how.
However, I successfully used MSAL with Azure AD.
MSAL seems to be a good library to use it generally with any IDPs.
According to the reply from the MSAL.NET GitHub discussion, MSAL.NET only supports Azure identity providers, so as of September of 2022, it would not work with third-party providers. The third-party support may be added later, but no timeline at this point.
PROVISO
I believe you're asking about MSAL.JS, as using MSAL.NET with a non-MS OpenID Connect provider is unnecessary, as Microsoft.AspNetCore.Identity provides sufficient support for social logins and vendors of custom OpenID Connect servers provide own extensions (see IdentityServer docs and OpenIdDict samples)
ANSWER
Yes, it's possible to use a non-MS OIDC provider with MSAL.JS since October 2020.
You'd have to specify extra auth properties: protocolMode: 'OIDC' and knownAuthorities: ["your-id-server.com"]. See the official docs on the parameters of #azure/msal-browser.
If you follow the official JavaScript examples then the config would look like:
auth: {
clientId: "YOUR-CLIENT-ID",
authority: "https://your-id-server.com",
knownAuthorities: ["https://your-id-server.com"],
redirectUri: "https://you-client-app.com",
protocolMode: "OIDC"
}
HISTORY
Till this PR was merged 16-Oct-2020, MSAL worked with MS end-points exclusively. So the #leastprivilege's answer of 2017 was correct back then.
Thankfully, issue requests 1555 and subsequently 2120 helped to change the tide.
I've posted a similar question about the more general case, but this question deals specifically with RTMP.
We have an Adobe AIR app written in AS3 that can view live video streams from other parties. That being said, when trying to call BitmapData.draw() on one of those remote video streams (technically we're calling ImageSnapshot.captureImage()), we're getting a 2123 error - a security sandbox exception. I've seen a lot of people refer to a real simple configuration in the AMS that will allow this to work for RTMP streams, but they keep posting broken links, links to posts that only vaguely mention this configuration, etc. The one thing I did find is something that I'm having trouble applying:
http://help.adobe.com/en_US/FlashMediaServer/3.5_SS_ASD/WS5b3ccc516d4fbf351e63e3d11a11afc95e-7ec3.html#WS5b3ccc516d4fbf351e63e3d11a11afc95e-7fcb
To make the above work, I've tried setting audioSampleAccess and videoSampleAccess both to "/", but to no avail. On the AMS, in Application.xml, I've set these configurations:
<FolderAccess>true</FolderAccess>
<AudioSampleAccess enabled="true">*</AudioSampleAccess>
<VideoSampleAccess enabled="true">*</VideoSampleAccess>
I've also seen references to setting up a wide-open cross-domain policy file, but I've seen people emphasize that it's not necessary, and I don't see any clear mention of where on the server that policy file needs to be. I have, however, started setting NetStream.checkPolicyFile to true, and I have placed a cross-domain policy file in the root directory of the website itself (as opposed to the AMS).
Please don't just give me another link, unless it's to a quick, clear explanation. How do you configure the AMS to allow people to capture screenshots from RTMP video streams? For the above article, I've tried setting videoStreamAccess and audioStreamAccess both to "/", and even it didn't work. We also need to be able to do this for P2P RTMFP streams, but that's really a different question. Thanks.
I have following FMS code to fix that error in application.onConnect method:
client.videoSampleAccess = "/";
client.audioSampleAccess = "/";
We want to replace a custom NPAPI interface between a browser based web application and an client side daemon process.
Is there a similar technology to Chrome's Native Client Messaging in Firefox?
js-ctypes[1] is probably the closest alternative for Mozilla.
https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes
I have a C++ module that I compile as a binary executable for native-messaging or as a library for js-ctypes. The difference between the two is primarily that native-messaging calls a binary executable and performs stdin/stdout data exchange, and js-ctypes opens a static/shared library (via dlopen) and calls exposed methods of your library which can return compatible data types[2] and optionally call a passed JavaScript callback method.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes
[2] https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/js-ctypes_reference/ctypes#Predefined_data_types
With new support for Mozilla 'Chrome' WebExtensions API seems like soon there will be a very similar technology to Chrome's Native Client Messaging.
At this time it's still on the 'List of APIs [mozilla] will likely support in the future'
Is it possible for a Chrome extension to listen for streaming audio from any of the browser's tabs? I would like to capture the streaming audio data and then analyse it.
Thanks
You could try 3 ways, neither one does provide 100% guarantee to meet your needs.
Before going into more detailed descriptions, I must note that Chrome extensions do not provide convenient tools for working on per connection level - sufficiently low level, required for stream capturing. This is by design. This is why the 1-st way is:
To look at other browsers, for example Firefox, which provides low-level APIs for connections. They are already known to be used by similar extensions. You may have a look at MediaStealer. If you do not have a specific requirement to build your system on Chrome, you should possibly move to Firefox.
You can develop a Chrome extension, which intercepts HTTP-requests by means of webRequest API, analyses their headers and extracts media urls (such as containing audio/mpeg MIME-type, for example, in HTTP-headers). Just for a quick example of code you make look at the following SO question - How to change response header in Chrome. Having the url you may force appropriate media download as a file. It will land in default downloads folder and may have unfriendly name. (I made such an extension, but I do not have requirements for further processing). If you need to further process such files, it can be a challenge to monitor them in the folder, and run additional analysis in a separate program.
You may have a look at NPAPI plugins in general, and their streaming APIs in particular. I can imagine that you create a plugin registered for, again, audio/mpeg MIME-type, and receives the data via NPP_NewStream, NPP_WriteReady and NPP_Write methods. The plugin can be wrapped into a Chrome extension. Though I made NPAPI plugins, I never used this API, and I'm not sure it will work as expected. Nethertheless, I'm mentioning this possibility here for completenees. This method requires some coding other than web-coding, meaning C/C++. NB. NPAPI plugins are deprecated and not supported in Chrome since September 2015.
Taking into account that you have some external (to the extension) "fingerprinting service" in mind, which sounds like an intelligent data processing, you may be interested in building all the system out of a browser. For example, you could, possibly, involve a HTTP-proxy, saving media from passing traffic.
If you're writing a Chrome extension, you can use the Chrome tabCapture API to record audio.
chrome.tabCapture.capture({audio: true}, function(stream) {
var recorder = new MediaRecorder(stream);
[...]
});
The rest is left as an exercise to the reader; MDN has more documentation on how to use MediaRecorder.
When this question was asked in 2013, neither chrome.tabCapture nor MediaRecorder existed.
Mac OSX solution using soundflower: http://rogueamoeba.com/freebies/soundflower/
After installing soundflower it should appear as a separate audio device in the sound preferences (apple > system preferences > sound). Divert the computer's audio to the 2ch option (stereo, 16ch is surround), then inside a DAW, such as 'audacity', set the audio input as soundflower. Now the sound should be channeled to your DAW ready for recording.
Note: having diverted the audio from the internal speakers to soundflower you will only be able to hear the audio if the 'soundflowerbed' app is actually open. You know it's open if there's a 8 legged blob in the top right task bar. Clicking this icon gives you the sound flower options.
My privoxy has the following log:
2013-08-28 18:25:27.953 00002f44 Request: api.audioaddict.com/v1/di/listener_sessions.jsonp?_method=POST&callback=_AudioAddict_WP_ListenerSession_create&listener_session%5Bid%5D=null&listener_session%5Bis_premium%5D=false&listener_session%5Bmember_id%5D=null&listener_session%5Bdevice_id%5D=6&listener_session%5Bchannel_id%5D=178&listener_session%5Bstream_set_key%5D=webplayer&_=1377699927926
2013-08-28 18:25:27.969 0000268c Request: api.audioaddict.com/v1/ping.jsonp?callback=_AudioAddict_WP_Ping__ping&_=1377699927928
2013-08-28 18:25:27.985 00002d48 Request: api.audioaddict.com/v1/di/track_history/channel/178.jsonp?callback=_AudioAddict_TrackHistory_Channel&_=1377699927942
2013-08-28 18:25:54.080 00003360 Request: pub7.di.fm/di_progressivepsy_aac?type=.flv
So I got the stream url and record it:
D:\Profiles\user\temp>wget pub7.di.fm/di_progressivepsy_aac?type=.flv
--18:26:32-- http://pub7.di.fm/di_progressivepsy_aac?type=.flv
=> `di_progressivepsy_aac#type=.flv'
Resolving pub7.di.fm... done.
Connecting to pub7.di.fm[67.221.255.50]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [video/x-flv]
[ <=> ] 1,234,151 8.96K/s
I got the file that can be reproduced in any multimedia pleer.
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/