TIBET Short Topics


  • Configure TIBET to work with different commonly-used technologies.

Configuring TIBET to use Cross-Origin Resource Sharing (CORS)

TIBET can be used with servers that support CORS. Be aware, however, that TIBET wants to send extra HTTP headers that need to be taken into account when configuring CORS support in the server. This is to provide enhanced functionality when using TIBET.

For instance, if you want to send JSON using the standard MIME type of application/json in the Content-Type header, CORS forces that to be a 'complex request'. Other restrictions include an incredibly restricted set of HTTP verbs and headers:

Simple Verbs


Simple Headers

content-type (but only certain types)

Therefore, some of the headers and verb combinations that TIBET wants to send will force CORS into complex request mode where where it will send an OPTIONS preflight check before actually performing the call.

Note that TIBET can be configured to try to use 'simple CORS' only, but it will not even try to send the request if the domain is cross-origin and the request contains a non 'simple request' combination of verbs and headers (it will log warnings for these). Therefore, TIBET ships with this flag set to false, but you can switch it on should you want to try:

TP.sys.setcfg('http.simple_cors_only', true);

For normal operations, though, here is the complete set of HTTP headers that TIBET will send and that your CORS-configured server needs to return as 'ok' as part of its OPTIONS preflight check:


TIBET also likes to have access to some extra verbs, especially when using it with WebDAV servers. Again, some of these verbs force CORS into a 'complex request' mode.


Configuring the AWS Passthrough to use with TIBET

The TIBET AWS Passthrough allows CORS-based access to any AWS service from any browser running TIBET.

It consists of:

  • An AWS Lambda function containing a 'general dispatch' function that allow remote configuration of method and parameters.
  • A configured AWS role with a set of AWS policies
  • An AWS Cognito Identity Pool
  • A small set of TIBET client-side code that will allows easy access to the chosen AWS services.

NOTE: The AWS Passthrough is meant for development purposes only. Use a restricted set of policies and identities when deploying your application.

To install and use the TIBET AWS Passthrough, see the separate GitHub project and follow the instructions there:


Configuring CouchDB to use with TIBET

CouchDB is an excellent back-end server companion technology to TIBET! There are two reasons for this:

  • The protocol used is HTTP. This allows direct access from TIBET using CORS, should you choose to configure it that way. TIBET has built-in supporting classes that manage an HTTP connection with CouchDB.

  • All aspects of the database are accessible via REST URLs. Again, this makes it ideal for a technology such as TIBET that uses Web technologies and concepts at its core.

Here are some tips when setting up CouchDB for use with TIBET:

  1. Make sure your database is fully set up! This means you should've chosen the number of nodes that you want distributed (which can be 1, if you prefer), etc. If CouchDB is not fully configured, errors around the changes feed, etc. will show up, but not as errors from CouchDB. These may manifest themselves as errors in the Chrome network panel as net::ERR_INVALID_CHUNKED_ENCODING errors.

  2. If you're configuring CouchDB to be directly accessible from TIBET, you should set your CouchDB cors.headers configuration variable to the CORS HTTP headers that TIBET will send. See Configuring TIBET to use Cross-Origin Resource Sharing (CORS) for more information.

  3. If you're configuring CouchDB to be directly accessible from TIBET, you should set your CouchDB cors.methods configuration variable to the CORS HTTP verbs that TIBET will send. See Configuring TIBET to use Cross-Origin Resource Sharing (CORS) for more information.

  4. Because you are required to provide a login when you set up your CouchDB to avoid the first problem in this list, there is no longer the notion of 'admin party'. Therefore, all change feed subscriptions will happen over an authenticated connection. Since this is the case, the CORS standard does not support a 'access control origin' of * when using 'complex CORS' - it forces you to configure a real origin. This can be done by setting the CouchDB cors.origins configuration variable to something like: (note how we include port number, but not a trailing slash).


The HTTP code managing CORS is defined in ~lib/src/tibet/kernel/TIBETHTTPPrimitivesPre.js.