Security
Botize not only allows your application entry point to make use of SSL (HTTPS), but actually strongly encourages it.
Plain HTTP should be limited to testing environments only, and in fact, future versions of the API could disallow it and support HTTPS entry points only.
When you register an application you can provide a username and password that Botize will include in any request to your server. This is optional (your server can simply ignore any authentication data) but strongly recommended, since this is the only way to prevent anyone else from accessing your server claiming to be Botize. These credentials are sent in the HTTP header by using the basic HTTP authentication mechanism (¡and this is yet another good reason to use HTTPS!). Future versions of the API could allow other authentication mechanisms as well.
Aside from this “B2B” authentication mechanism, there is a per-task user authentication mechanism for functions that make use of an external service and require the user to provide his credentials for that service. There are two user authentication modes: simple (a username+password pair), and web (for external, web-based authentication services such as the ones provided by Twitter or Facebook). At this time there is a restriction in the user authentication mechanism: it is not possible to use two different authentication services for the the trigger and the action of a task, both must authenticate to the same service. However, it is possible to specify different user accounts for the trigger and the action.
Plain HTTP should be limited to testing environments only, and in fact, future versions of the API could disallow it and support HTTPS entry points only.
When you register an application you can provide a username and password that Botize will include in any request to your server. This is optional (your server can simply ignore any authentication data) but strongly recommended, since this is the only way to prevent anyone else from accessing your server claiming to be Botize. These credentials are sent in the HTTP header by using the basic HTTP authentication mechanism (¡and this is yet another good reason to use HTTPS!). Future versions of the API could allow other authentication mechanisms as well.
Aside from this “B2B” authentication mechanism, there is a per-task user authentication mechanism for functions that make use of an external service and require the user to provide his credentials for that service. There are two user authentication modes: simple (a username+password pair), and web (for external, web-based authentication services such as the ones provided by Twitter or Facebook). At this time there is a restriction in the user authentication mechanism: it is not possible to use two different authentication services for the the trigger and the action of a task, both must authenticate to the same service. However, it is possible to specify different user accounts for the trigger and the action.