Cookie Consent by TIBET





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





Configuring TIBET 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 TIBET AWS Passthrough (DEV ONLY!)

NOTE: The TIBET AWS Passthrough is a DEVELOPMENT-ONLY technology intended to make prototyping more effective. It is NOT SECURE and should NEVER BE USED IN PRODUCTION.

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.

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


Configuring CouchDB for use with TIBET/TDS/TWS

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 (i.e. not proxying the connection to CouchDB from the browser, but allowing direct access), you need use CORS. Therefore, you should set your CouchDB headers configuration variable in the [cors] section of your CouchDB configuration file to the CORS HTTP headers that TIBET will send. See Configuring TIBET Cross-Origin Resource Sharing (CORS) for more information.
  3. Additionally, if you're configuring CouchDB to use CORS, you should set your CouchDB methods configuration variable in the [cors] section of your CouchDB configuration file to the CORS HTTP verbs that TIBET will send. See Configuring TIBET 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' for CouchDB (CouchDB itself eliminated the notion of admin party in CouchDB versions 3.X and higher anyway).
    Therefore, all communication with CouchDB 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 origins configuration variable in the [cors] section of your CouchDB configuration file to something like: (note how we include the port number, but not a trailing slash).
  5. TIBET supports both HTTP Basic authentication and CouchDB cookie token authentication. To set which scheme to use, change the TIBET couch.auth_scheme configuration variable to either basic or cookie.
  6. If your application is going to use cookie authentication and you're running a modern browser, like Google Chrome, that supports the SameSite cookie authentication scheme, you need to set the CouchDB same_site configuration variable in the [couch_httpd_auth] section of your CouchDB configuration file to none.
  7. If you're going to be using SameSite cookies, you need to configure CouchDB to use SSL. Note that, the standard CouchDB SSL configuration will run CouchDB under port 6984 instead of 5984, so make the necessary adjustments in any TIBET CouchDB examples.

To configure the latest CouchDB to use SSL, follow the instructions at: HTTPS (SSL/TLS) Options.


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