Skip to main content
Embedding

Signed URLs and allowed sites

Signed URLs give visitors short-lived access to private assets from your own website. Allowed sites limit which websites can show them.

Written By Nira.app

Last updated About 3 hours ago

Signed URLs let your website or app give a visitor short-lived access to one private asset. The visitor needs no Nira account and no password. Your server creates the URL when the visitor opens your page, and the URL stops working at the expiry time your server sets, at most 4 hours later.

Allowed embedding sites lets you choose which websites can show your Nira assets inside their pages. Block direct access makes signed URLs work only inside another web page, so a copied URL does not open in a browser tab.

Use them together when your own portal already decides who may see an asset. The portal signs a URL for each visitor, and only your portal's site can display it.

An Admin sets up keys and sites in Nira. A developer adds code to your server that signs the URLs, following the Signed URLs page on our developer site.

Requirements

Signed URLs, Allowed embedding sites and Block direct access need a Growth or Enterprise plan with the Role-based Access Control for iframes add-on. An Admin can add the Role-based Access Control for iframes add-on from Admin Options > Billing. If your organization has a custom package, Contact us to add it.

To renew a signed URL while a visitor is on the page, you also need the Viewer API add-on.

If the Role-based Access Control for iframes add-on is removed later, signed URLs stop opening and Nira stops applying your allowed sites and Block direct access. Nira keeps your keys and your list of sites.

Open the Embedding page

Log in to your Nira site as an Admin. Open the menu in the upper left corner, then click Embedding under Admin Options.

The page has four sections: Embed the Nira viewer, Build on the Nira viewer, Signed URLs and Allowed embedding sites. Without the Role-based Access Control for iframes add-on, the last two sections are locked and show a button to add it.

Add a signing key

Your server signs each URL with a private key that only you hold. Nira checks the signature with the matching public key, which you add on the Embedding page.

  1. Under Signed URLs, click Generate key or Use your own key.

  2. Enter a Name so you can tell your keys apart.

  3. Optional: pick an Expiry date (optional). The key stops working at the end of that day.

  4. With Use your own key, paste the public key into Public key (PEM).

  5. Click Generate or Add.

Generate key

Nira makes a key pair in your browser and shows the private key once, in the Your new private key window. Click Copy or Download .pem, store the private key somewhere safe, then click Done.

Nira keeps only the public key, so the private key cannot be shown again. If it is lost, delete the key and add a new one.

Use your own key

Paste a PEM public key that starts with -----BEGIN PUBLIC KEY-----. It must be an ES256 key (curve P-256).

To make a P-256 key pair with OpenSSL, run:

openssl ecparam -name prime256v1 -genkey -noout -out nira-signing-key.pem
openssl ec -in nira-signing-key.pem -pubout -out nira-signing-key.pub.pem

Paste the contents of nira-signing-key.pub.pem into Nira. nira-signing-key.pem is the private key your server signs with.

Your keys

The table under Signed URLs shows each key's Name, Key ID, Created by, Created, Last used and Expires. Click a Key ID to copy it. Your developer puts the Key ID in every signed token.

You can have up to 5 keys. A key past its expiry date still counts toward the 5 until you delete it. Each public key can be added once.

Keep the private key on your server. Never put it in a web page or an app. Anyone who holds it can sign URLs for any asset in your organization.

Delete or replace a key

Click the trash icon on the key's row, then click Delete. URLs signed with that key stop working within a minute.

To replace a key without breaking URLs in use, add the new key, switch your server to sign with it, then delete the old key.

Allowed embedding sites

This setting chooses which websites can show your Nira pages inside their own pages. Pick one of three options:

Option

Effect

Anywhere

Any website can show your assets. This is the default.

Only on specific sites

Only the sites you list can show your assets.

Nowhere

No website can show your assets.

Each change saves and takes effect as soon as you make it.

This setting controls where your assets can appear, not who can open them. Signed URLs, user roles and passwords still decide access. It applies to every page on your Nira site, including asset pages, inspection links, signed URLs and the sign-in page.

Add sites

Choose Only on specific sites, type a site in the box, then click Add or press Enter. To remove a site, click the trash icon next to it.

Until you add a site, no website can show your assets, and the page warns: "Embedding is blocked until you add a site."

  • Enter a site name, like example.com.

  • *.example.com covers every subdomain of example.com, but not example.com itself. List both if you need both.

  • A site without https:// or http:// in front matches https:// pages only. For a local test page, add the scheme and port, like http://localhost:3000.

  • A pasted link that starts with https://, like https://www.example.com/portal/page, is shortened to its site, https://www.example.com.

  • Spaces, quotes, commas and semicolons are refused.

  • You can list up to 20 sites, with at most 2,048 characters in total.

If you show your own assets inside callouts or descriptions, list your Nira site, like yourcompany.nira.app, and your custom domain if you have one.

Pages inside other apps

The browser checks every page around your asset, not only the page that holds it. If your page is itself shown inside another app, such as SharePoint, Teams, Notion, Google Sites or a Webflow preview, list that app's site too.

A callout in another Nira organization that shows one of your assets is blocked unless you list that organization's Nira site.

Block direct access

Block direct access is under Signed URLs. It is on by default and marked Recommended. Turning it on or off saves right away.

While it is on, a signed URL works only inside another web page, in an iframe. If someone opens the URL in a browser tab, the page shows "This link only works on the website it came from." instead of the asset. Renewal with the Viewer API keeps working inside the iframe.

Block direct access does not choose which websites can show the URL. Allowed embedding sites does that. Choose Only on specific sites and list your sites to stop other websites from showing your signed URLs.

Block direct access relies on the browser reporting that the page is loaded inside another page. Browsers that do not report this, such as Safari before 16.4, open the URL in a tab even while the option is on. Short expiry times stay the main protection.

How the settings work together

This table shows where a signed URL opens for each combination.

Allowed embedding sites

Block direct access on

Block direct access off

Anywhere

Inside a page on any website

Inside a page on any website, and in a browser tab

Only on specific sites, with sites listed

Inside a page on the listed sites only

Inside a page on the listed sites, and in a browser tab

Only on specific sites with no site listed, or Nowhere

Nowhere

In a browser tab only

Only on specific sites with Block direct access on gives the tightest control. When you have a key and one of the combinations in the last row is set, the Signed URLs section shows a warning.

For your developer

Your server signs a short token for each visitor and puts it in a URL on your Nira site:

https://yourcompany.nira.app/s/<token>

The token names one asset, an access level and an expiry time, and carries the Key ID from the Embedding page. A token can last at most 4 hours. With the Viewer API, your page can renew it while the visitor is on the page.

The Signed URLs page on our developer site has the token format, code samples for Node, Python and C#, renewal with the Viewer API, and the error reasons your page receives.

Access levels

view gives read-only access. The visitor can look at the asset and its callouts. Nothing the visitor does is saved, and reports are not available.

inspection gives the same access as an inspection link. The visitor can create, edit and delete callouts and photo markups, and can create and read reports.

A valid token opens the asset whatever its visibility setting, including Private. If the asset has a password, the signed token takes the place of the password.

The visitor sees one of these messages instead of the asset:

Message

Cause

This link has expired.

The expiry time your server set has passed.

This link is not valid.

The token is wrong, or it was signed with a key that was deleted or is past its expiry date.

This link does not give access to this asset.

The asset is missing or archived, or the Role-based Access Control for iframes add-on is not active.

Too many requests for this link.

The same URL, or your organization's signed URLs, were loaded too many times in a short period.

This link only works on the website it came from.

Block direct access is on and the URL was opened in a browser tab.