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 4 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.
Under Signed URLs, click Generate key or Use your own key.
Enter a Name so you can tell your keys apart.
Optional: pick an Expiry date (optional). The key stops working at the end of that day.
With Use your own key, paste the public key into Public key (PEM).
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.pemPaste 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:
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.comcovers every subdomain ofexample.com, but notexample.comitself. List both if you need both.A site without
https://orhttp://in front matcheshttps://pages only. For a local test page, add the scheme and port, likehttp://localhost:3000.A pasted link that starts with
https://, likehttps://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.
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.
When a link stops working
The visitor sees one of these messages instead of the asset:
Was this helpful?
Still need help? Share an idea