I am follwing this http://www.html5rocks.com/en/tutorials/webrtc/infrastructure tutorial. This tutorial or discussion is about TURN/STUN servers. And this tutorial add turn and stun server code like below.
{
'iceServers': [
{
'url': 'stun:stun.l.google.com:19302'
},
{
'url': 'turn:192.158.29.39:3478?transport=udp',
'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
'username': '28224511:1379330808'
},
{
'url': 'turn:192.158.29.39:3478?transport=tcp',
'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
'username': '28224511:1379330808'
}
]
}
Can i use this credentials to make Web-RTC communication between browsers (on different pcs).
And ı read this tutorial also Implementing our own STUN/TURN server for WebRTC Application. According to this tutorial when we use turn server for nat and firewalls, using stun server is unnecessary. And this tutorial added this code for stun and turn server.
var pc_config = {"iceServers": [{"url":"turn:my_username#<turn_server_ip_address>", "credential":"my_password"}]};
pc_new = new webkitRTCPeerConnection(pc_config);
What is "turn_server_ip_address" or what is "my_password" ? how can ı know this credential ?
those credentials provided in the examples are EXAMPLES, you cannot use them in a product.
Most TURN servers require credentials to utilize because of the possible high network usage because of relaying the SRTP/SRTCP packets. STUN servers on the other hand are usually not protected as there is not much computing power or network utilization when using them for candidate gathering.
There are open turn servers(NUMB for example, you can set up a username and password to use against their servers) out there that you can test against but I would suggest creating your own in some sort of cloud computing service if you are creating a product.
In short, you know the credentials and IP address of the TURN server because either you signed up for the service you are using or it is your server.
Related
I am trying to subscribe to Signalwire phone numbers using Relay SDK with following code:
this.client1 = new Relay({
project: 'myprojectid',
token: jwtToken,
})
this.client1.subscribe({
protocol: "WSS",
channels: ["channel1", "channel2"]
}).then(r => {
console.log(r);
})
It throws an error:
"code": -32004,
"message": "Ignored 'blade.subscription' request because the protocol is not available"
I tried searching documentation, but could not find about how I can subscribe to channels using Relay SDK. I have also tried other protocols such as "TLS", "TCP" or "http, https" etc but did not succeed.
Please share any documentation for subscribing to channels or phone numbers.
It's not possible from this post to tell if you're using the SignalWire SDKs exclusively, if you're working from third party tools, or if you're doing your own setup. Depending on that and on what you're specifically looking to do with these, this might be a question of setup or it might not be possible.
With all that in mind, if you could reach out to SignalWire support (from your SignalWire space, select 'Help and Support' at the top right and then Submit a New Support Request) we can take a look at your setup and work through this with you.
I'm using Doxygen to generate documentation on a C++ project. I want to share this documentation with various team members without them having to build the docs themselves. In an ideal world, there's a service to privately host the static HTML that's generated from Doxygen, and gate it behind some sort of login. I think literally all this service needs to do is have some authentication middleware before serving the HTML. Just password protecting a directory is not good enough for what I'd like to do.
Does anyone know of a service like this that already exists? Am I taking the wrong approach?
What you are asking for is a service that host static pages but provide the authentication functionality. I don't know if something like that exists and I have not found anything in a quick search.
However, there's another approach, much more simple. Just generate the documentation and upload it wherever you want that requires authentication (Google Drive, a private repository in GitHub or Bitbucket, etc). Give access to your team members and they will just have to keep it up to date with the remote one and open the index.html locally in their browsers.
Azure has a static web app host available.
You can configure it so users must log in before anything is served up.
This is a bare bones config that will require people log into an app reg I made available to them, otherwise it will redirect to the azure ad login page.
We are already using Azure for our cloud needs, so this wasn't much to stand up for the documentation host.
Custom authentication in Azure Static Web Apps
Authentication and authorization for Azure Static Web Apps
{
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/TENANT_ID",
"clientIdSettingName": "AZURE_CLIENT_ID",
"clientSecretSettingName": "AZURE_CLIENT_SECRET"
}
}
}
},
"routes": [
{
"route": "/*",
"allowedRoles": [
"authenticated"
]
}
],
"responseOverrides": {
"401": {
"statusCode": 302,
"redirect": "/.auth/login/aad"
}
}
}
I'd like to limits API access from one or more domains - in other words I have a set of exposed API endpoints but I only want to respond to specific remote servers.
I intend to issue tokens to the servers that I intend to respond to but I want to ensure that I'm really dealing with the right servers in case the tokens become public knowledge.
I thought I would be able to use Origin or Referrer from the HTTP headers but perhaps because I'm sitting behind an Nginx front end, those headers don't always seem to be visible.
Any suggestions gratefully received.
You can't find domain names by ip (nslookup/dig $IP) becausethe reverse resolution requires an entry in the reverse zone (dns) configured for that ip. Not everyone sets up a reverse zone and, more importantly, many domain have just an A record configured.
Using other informations coming from the request itself, IMHO, are not a valid solution because these information can be forged so there's an high chance they make be "fake".
The best solutions I can suggest you are:
Filter by ip: if you know who's going to call your api, they know what's the ip they're using to call your webserver. Configure apache so allow access to such ips.
Configure a client side authentication on your api so only those with a valid and authorized certificate (which doesn't need to be signed by a valid CA: you can create and use your custom CA) will be able to connect.
Limiting CORS / origin headers is one way if your API calls are coming from client side.
If its from server side call, IP is one way, but not guaranteed if there are many network hops in between and references are not passed by load balancers.
May be you can try something like this (Node.js):
const whitelist = ['https://www.example.com','https://www.example.com'];
const corsOptions = {
origin: (origin, callback) => {
if(whitelist.indexOf(origin) !== -1){
callback(null, true)
}else{
callback(new Error('Not allowed by CORS'))
}
},
optionsSuccessStatus: 200
}
replace https://www.example.com with your domains.
I wants to authenticate/authorize clients on vernemq broker. This are two hooks I'm interested in:
auth_on_register
auth_on_subscribe
I have setup above hooks and endpoints for them. On new register and subscription, I'm able to log the POST request params.
Related vernemq docs can be found here
Question:
Can we pass some custom variables in client request, so that we can handle auth.
If not, then can ssl be good alternative here, please include procedure for that?
Details:
by enabling auth_on_register we can get POST request to corresponding endpoint, with params:
{
"peer_addr": "127.0.0.1",
"peer_port": 8888,
"username": "username",
"password": "password",
"mountpoint": "",
"client_id": "clientid",
"clean_session": false
}
you can see that it is using username and password for auth purpose, do vernemq or mqqt in general provide facility to send custom params e.g. auth_token?
I have read that we can configure ssl certificates also, so if there's no facility for custom params then I would to go with this, or any other suggestion?
I am trying to perform some actions on the Tableau server via REST API for which I require the Auth token. I tried using the signin API from Postman and it works like a charm. However the same code is giving "Bad Request" error whe tried calling from javacript code from my webpage.
var dataVal = {
"credentials": {
"name": "admin",
"password": "admin",
"site": {
"contentUrl": "MySite"
}
}
};
$.ajax({
contentType: 'application/json',
data: JSON.stringify(dataVal),
dataType: 'jsonp',
success: function (data) {
console.log("call succeeded");
},
error: function (request, textStatus, errorThrown) {
console.log(request.getAllResponseHeaders());
},
processData: false,
type: 'POST',
url: 'http://mytableauserver/api/2.6/auth/signin'
});
The above code return token, siteid, userid from postman but return ""BAD REQUEST" error from javascript code. Any pointers will be highly appreciated.
For anyone else looking, Tableau now supports CORS but only on Tableau Server at this point.
Enabling CORS on Tableau Server for the REST API
For security, most web browsers restrict HTTP requests to the same origin. That is, to
access a resource on a server through an API, the request must come from the same
origin (server), or a proxy must be set up to handle the request.
Tableau Server now supports Cross-Origin Resource Sharing (CORS), so you can do away
with your proxy and call the REST API from the browser. The CORS mechanism is
currently only enabled for Tableau Server, and can be turned on by server
administrators in a couple of steps using the TSM command-line tool. To learn more,
see the description of the vizportal.rest_api.cors.allow_origin option in tsm
configuration set Options. As a security measure, you should make API calls to Tableau
Server using the HTTPS protocol (SSL or TLS). See Using HTTPS (SSL/TLS) for API Calls.
Add the origins that need access to the Tableau Server.
Determine the origins (servers) you want to allow access to the REST API, and use the
tsm configuration set command with the vizportal.rest_api.cors.allow_origin option.
For example, to grant access to one two origins, https://mysite and https://yoursite,
you would stop the server (tsm stop) and then use the following command:
tsm configuration set -k vizportal.rest_api.cors.allow_origin -v
https://mysite,https://yoursite
You can enter multiple origins. Use a comma to separate the entries.
Note: You could also use an asterisk (*) as a wild card to match all sites. This is
not recommended as it allows access from any origin that has access to the server and
could present a security risk. Do not use an asterisk (*) unless you fully understand
the implications and risks for your site.
Enable CORS on Tableau Server.
Use the tsm configuration set command with the vizportal.rest_api.cors.enabled option.
The default setting is false, so set this to true as follows:
tsm configuration set -k vizportal.rest_api.cors.enabled -v true
Update your Tableau Server configuration (tsm pending-changes apply) to restart
Tableau Server and make the changes take effect. Only the origins you specify will
have access.
https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_concepts_fundamentals.htm