Application Settings

An application is the deployment of something you've built in Qik. It can be a website or web app with its own domain and interface, or simply an API key that a script or integration uses to talk to Qik. This article walks through every setting on an application and what it does.

Creating an application

Go to Apps and, under Applications, click New Application. Choose one of:

• New Website / Web Application: an application with a rendered interface that visitors open in a browser. It starts on a free .sandbox.qik.dev address, which you can later swap for your own domain.
• API Key: a headless application with no domain or interface, just an access token for scripts and integrations. Give it a title and choose the scopes it's stored in. Login and signup are switched off.

Creating a new interface also offers to set up a production and a staging application for you. See Staging, Production and Milestones.

Many settings below only appear once the application has a Primary Domain Name, because they only apply to websites.

Configuration tab

Domain details

• Primary Domain Name: the address the site is served on, without http:// or slashes. Leave it blank for an API-key-only application. Each domain can belong to only one application across Qik.
• Secondary Redirect Domains: extra addresses that redirect visitors to the same page on the primary domain.
• Custom Domain Details: the DNS records to add at your domain provider.

See Custom Domains and SSL for the full setup.

Encryption and Security

• Static Access Token: the application's API key. It never expires. Use the copy button to grab it.
• Regenerate token: issues a new token. The old one stops working immediately, so update every script, integration or embed that uses it. Visitors who already have a site on this application open will need to reload.
• Force SSL: redirects http:// visits to https://. Only turn this on once a certificate covers the domain.

Treat website tokens as public. A website's token is sent to every visitor's browser, so anyone can see it. That's expected: what it can do is limited by the Application Permissions you grant (see below). Only grant what is safe for anyone on the internet to see or do.

User Authentication

These settings control whether people can sign in to your website or app with an app login. App logins are separate from logins to the Qik dashboard, and the same email address can have one of each.

• Enable User Signup: lets people create their own login through the application. If signup is on, anyone who signs up receives the User Permissions below.
• Enable User Login: lets existing app logins sign in.
• Require MFA: asks people signing in with a username and password for a one-time code sent by email. Doesn't apply to sign-ins through an OAuth provider.
• Passcode: when set, visitors must enter this passcode before they can use the site at all. Require Passcode shows whether one is set. It's handy for preview links, kiosks or a simple shared-access site. After 10 wrong attempts within 15 minutes, further attempts from that visitor are blocked for a while.
• OAuth Configuration: choose which OAuth integrations people can sign in with (shown when login or signup is enabled).
• Password Page: a page on your own domain, such as /set-password, where people choose a password. Put the Password Reset block on that page. Invitation and password-reset emails then link there instead of to a Qik page. Leave it blank to use Qik's page.
• Email Template: the email layout used for this application's invitation and password-reset emails. Leave it blank to use your organisation's default template.

Inviting people: to invite existing app logins, select them in your list of logins (see Managing Users and Access Passes) and choose Send App Invitation. Pick the application (only applications with login enabled are offered). Each person receives a welcome email with a link to choose a password, which then signs them in to that application. This works even when self signup is turned off.

User Interface

• Interface: the interface (pages, blocks, menus and styles) this application renders.
• Interface Version: which version of the interface to show: Current working draft, Latest published version, Latest production milestone or Specific version. With Specific version you also choose the Interface Snapshot. See Staging, Production and Milestones.
• Shortcut Icon: the favicon shown in browser tabs and bookmarks, and when the site is saved to a home screen. Choose an image from your media library. Square images work best.

The favicon belongs to the application, not the interface. Set it here with Shortcut Icon. The image in the interface's SEO settings is the social-sharing preview image, not the favicon. Changing the Shortcut Icon takes effect without publishing.

Support Email Address

A contact address for questions, or requests to delete accounts or content. It's shown for applications with a domain or a mobile bundle.

Mobile

If this application runs as an iOS or Android app, enter its Application Bundle ID here. The other engine and version fields are for Qik-built mobile apps. Leave them alone unless support asks you to change them.

Hosted Files

Serve a file exactly as entered at a fixed path on your domain, ahead of the website itself. Common uses are .well-known/apple-app-site-association, .well-known/assetlinks.json, and domain-verification files from services like search consoles. Enter the Path (without the domain), paste the Content, and optionally set a Content Type (it defaults to application/json).

Allow Embedding On

By default other websites can't show your Qik site inside an iframe. To allow it, list the sites that may embed it as origins, such as https://www.acme.com, or enter * to allow any site. See Embedding Forms and Content.

Meta Data and status

Click More on the Meta Data panel to see the application's scopes, tags and Status. Setting the status to inactive stops the application's access token working, so scripts and integrations using it are refused and a website on it can no longer load content through it. To take a website offline completely, clear its Primary Domain Name or delete the application. Deleting also frees the domain for use elsewhere.

Permissions tab

An application has two sets of permissions, each made of roles granted in scopes:

• Application Permissions: what the application can do on its own. Every request it makes gets these, including requests from visitors who aren't signed in. For a public website this is usually a "website visitor" role that can view the images, articles and other content the site displays. When Qik creates applications for a new interface, it sets up a basic website visitor role for you.
• User Permissions (shown when login or signup is enabled): extra permissions for anyone signed in with an app login. They add to the application permissions and to the person's own access passes. Visitors who aren't signed in don't get them.

Permissions are additive, so a signed-in person gets the application's permissions, plus the user permissions, plus their own. For worked examples, see Application Access Control and Roles and Permissions.

Grant only the fields a site actually needs. This keeps private data out of public reach and makes pages load faster.

Integrations tab

• Google Tag Measurement ID: add your Google Analytics ID (for example G-XXXXXXXXXX) to load Google's tag on the website.
• OAuth Configuration: the OAuth integrations people can use to sign in.
• FCM Integration: a Firebase Cloud Messaging integration for push notifications in a mobile app.

Redirects tab

For websites, add path redirects, for example from /about to /about-us. Paths are matched exactly (a trailing slash is ignored). The To value can be a path on your site or a full https:// address on another site. Redirects are permanent (301), and the visitor's query string is carried over when the destination doesn't have one. They're useful after restructuring a site, or when moving from an old website so existing links keep working.

When do changes take effect?

Changes to application settings (domains, favicon, redirects, permissions, passcode) apply without publishing the interface, usually within seconds. If a site still shows the old behaviour, open it with ?reload=true on the address or give it a few minutes.

Who can change applications?

Viewing and editing applications needs the matching permissions in a role. Anyone who can edit an application can also regenerate its token. Website-building tools may need to be enabled for your organisation. If you don't see Apps, contact support.

FAQs