Video Security and Privacy as you like it
Are you looking to create closed in video system where you can do everything and no one else can do anything unless you allow them?
With Ziggeo that is quite easy to do actually.
There are several things that are of interest and help us depending on which setup we want to utilize:
- We can specify which domains (and even subdomains) can use your application token
- we can allow which domains can use iFrame or oEmbed to show player or to show recorder
- we can set what permissions someone has, such as create, edit/update, read and delete, as well as more
- and we can use authorization tokens
Most of these settings are in your Manage section of your application. What this means is that you can set all of those cool features for each of the applications that you have, allowing you to easily create a secure setup that works for you for each client, or each domain that you have easily.
Authorization tokens are under their own section, and we will go over all of the points above, in order to guide you in how to create a very secure and private system, yet with much ease.
First, lets limit the tokens to be limited to your own website(s) only.
Authorized Domains
Why would you do that and why is it not done by default?
By default we allow any website to make a call to our service with a prerequisite that it specifies correct application token and video token. This is definitely the easiest way to set things up and it requires someone to know our system and your application token and video token to play back your video on their website.
If this was to happen for you by some chance (in our experience people just seem to prefer to prevent it rather than it actually happening first) you can quickly stop it using the Mange > Allowed Domains.
Once there, we would first remove the * (asterisk) as it is a wildcard that allows every website.
If you refresh the page on your website now, you will see the video that played just a moment ago not playing any longer.
Now, lets go back to the Ziggeo dashboard so that we can allow it. This is easy as we add our website domain and save it, after which refreshing the page on your website will again show us the video that we can play back.
Many people have public development domains, production, client area, help and alike. In such cases there are 2 different ways you can accomplish setting up the allowed domains:
- you can add each subdomain that you are using
- you can use wildcard.
Lets say that your website is example.com and that you also have dev.example.com, help.example.com and clients.example.com and all of them are going to use Ziggeo.
The first approach (adding all of them) would mean that you add into your allowed domains the following:
- example.com
- dev.example.com
- help.example.com
- clients.example.com
Doing it this way means that you will need to make changes in your dashboard if you were to (for example) redirect your clients from clients.example.com to dashboard.example.com at some point.
Using the wildcard you could set it up as following:
- *.example.com
If you were to change any of the subdomains that would not make any difference for your domains authorizations, as they would already be covered by the wildcard (well as long as the domain and TLD is the same).
Done! - Yup it was that easy to set up which domains are allowed and which are not.
Of course using the same, you could easily allow your localhost, your own website and the public website where your developers are working on the implementation for you. If you wanted, you could add any number of websites that you need.
Iframe and oEmbed Authorizations
If you do want to allow people to use your embeddings on their website, however want to easily manage if that would be video playback or recorder and what code, that is more than simple with Ziggeo just as well :)
Go to Manage > Iframe and oEmbed setups and you will see that it is just few clicks to allow specific website to be allowed to show your recorder, player or both. The recorder code is created for you and can be seen above the same options (under "Recorder Embed" segment), while for the player, you can find embedding codes under each Video preview (in Videos section).
Done! - Yup, again a simple and yet quite efficient way for you to utilize your Ziggeo application settings to quickly set the privacy of your videos to the level you like.
Authorization settings and tokens
Now onto the authorization settings. This section does require most of work, however unlike the ones above, it allows us to set it all up on embedding code level. This means that we can use different setups for each embedding if that is what we want, and while it would take a bit more to set up, it is what many call perfection - everything works as you want it and yet you go and you make it even better!
The settings that we can utilize in this section (Manage > Authorization Settings) allow us to specify settings about:
- video creation
- video edits/updates
- video playback
- video removal
- if videos can be played back without moderation
- if videos can be searched for through JavaScript calls
- if videos can be deleted automatically by our system
Now the first 4 settings are used in combination with authorization tokens, so we will come back to them and quickly go over the rest first.
If you are showing videos that are uploaded (always) by people that you trust such as your company employees, or if your videos are uploaded by your clients or community and only shown to your employees, then you might want to show them even if they are not moderated. In most cases however videos should likely be moderated.
By checking that option, our system will make sure that the only videos that can be played back are the ones that are approved through the Moderation page of your account.
- If you want to use code to approve videos, that is possible as well by using our API calls. It requires update video privilege so if you require those calls to be made with authorization tokens, that is possible as well. To see more about this head to our JS API page.
Going further we can also limit if the videos can be found through JavaScript code or not. It is good to mention that if you are using server side SDKs the index() function within each is considered safe as it will include your signature, so you really do not need to even have the JavaScript index() function to go through videos in such cases.
The last option on the list above was about automatically removing videos. We never remove the videos from your account, however you might want to have that happen for different reasons and after some specific timeframe. As such we have added the parameter that allows you to specify when the same can be deleted.
To make the embedding parameter work, the authorization settings must allow it, making sure that even if someone was to specify the removal, it would not work unless you have considered this first (when our system removes the video it does not require auth token).
We have covered a great deal and we are just starting on authorization settings, how nice it is that while there was some text to read, the setup was almost just few clicks! :)
When any action (creating, updating, reading or removing video) is taken and it requires auth tokens, you will see forbidden error unless correct auth token is provided.
We made our system smart in this context so that you can literally specify resource and action and a bit more than that. We suggest checking out the following section to see more: Authorization Tokens Docs.
With this setup you can quickly and easily set up per video, permanent, or temporary authorization tokens which follow your workflow, allowing you to authorize your managers to delete the video, your support to update the same and your customers to just preview their own videos, or possibly to allow them to update videos, only immediately after recording it.
By default we just set the requirement for authorization tokens on the removal of the videos, while all other actions are allowed and as such depend on your own embedding setup.
How easy was that? :)
Hope you liked this introduction into these cool security and privacy setups you have available with Ziggeo. If you want to know more or would like to see more details on something, just let us know in the comments bellow or by contacting us.
-
In regards to the auth token generation in the dashboard of the application.
If I set the
- video creation
- video edits/updates
- video playback
- video removal
to require auth, then use the dashboard to create a server auth token with the grants like so
{
"grants": {
"create": {
"session_owned": true
},
"update": {
"session_owned": true
}
},
"session_limit": "1"
}Is it possible to use this auth token in the browser JS code?
From what I can gather, it should be provided in the ZiggeoApi.V2.Recorder attrs['server-auth'], but I still only get Forbidden 403 in the recorder when pressing the record button.
Thanks for your assistance.
0 -
You should be able to use the same in the JS. I would suggest however creating client side auth tokens for public facing setups.
For just playing around with it and to make setup easier, then using server side is best option (easy to create and maintain).
Now if your server-auth token is 1234567890 then the way to use it should be something like this:
var recorder = new ZiggeoApi.V2.Recorder({
element: document.getElementById("placeholder_element"),
attrs: {
responsive: true,
theme: "modern",
themecolor: "red",
'server-auth': '1234567890'
}
});
recorder.activate();For create you can also simply use:
"create": {
"all": true
}This way you are saying that you allow creation of videos without any specific requirements.
Do let me know how it goes for you.
1 -
I had success with the server-auth, and the grant example you provided. For some reason I had wrapped the grants in another object level like this.
{
"grants: {
"create": {
"all": true
}
}
}Thanks for sorting that out.
0 -
Glad to hear that it is sorted out Gavin :)
0
Please sign in to leave a comment.
Comments
4 comments