Branded Sign-in & Sign-up
Give an app its own public sign-in page, with the app's logo and name, at a URL of its own. People who sign up or sign in there become users of that app and nothing else: the app is their home app, and they never see the Strongly platform.
This is for apps you hand to customers or a team of their own: a client portal, a review tool, an internal app for a department. Open the app from the Apps page and use the Auth tab.
Turning it on
- Open the app's details page and choose the Auth tab.
- Switch on Enable branded sign-in for this app.
- Choose the URL name. It is the path of the app's sign-in page under your platform address, for example
https://<your-platform>/client-portal/. Lowercase letters, digits and hyphens only; the platform's own paths (apps,admin,apiand so on) are reserved, and two apps cannot share a name. - Save.
Turning on branded sign-in also turns on Home App for the app: a user who signs in through the branded page lands in the app and stays in it.
Pages
Once saved, the Pages list shows every public address the app now has, each with a copy button and an open-in-new-tab button:
| Page | Address |
|---|---|
| Sign in | https://<your-platform>/<url-name>/ |
| Sign up | https://<your-platform>/<url-name>/signup |
| Forgot password | https://<your-platform>/<url-name>/forgot-password |
| Sign out | https://<your-platform>/<url-name>/sign-out |
The sign-in page links to sign up and forgot password itself; share the sign-in address.
Password reset and email verification links sent to the app's users point back to these branded pages, never to the Strongly sign-in page.
Logo
Upload a small logo (PNG, JPG or SVG, under 200KB). It replaces the Strongly branding on every page above. Without one the pages show the app's name.
Who may sign up
| Setting | What it does |
|---|---|
| Allow public sign-up | On: anyone who reaches the sign-up page can create an account. Off: the sign-up page is closed and you add users yourself (the app's Permissions tab or the Home App tab). |
| New accounts | Instant: the account is usable right away. When the platform has email configured, the user first confirms their email address through the link they are sent. Approval: every new account waits until an administrator of the app activates it from the Users table below. |
| Allowed email domains | When set, sign-ups must use an email address at one of these domains (subdomains included). Leave empty to allow any address. |
Someone who signs up:
- gets an account with the app user role: they can use this app and nothing else on the platform;
- has this app as their home app: signing in takes them straight into it, full screen, with no platform navigation around it;
- appears in the Users table below, and in the app's Permissions and Home App tabs.
Users
The bottom of the Auth tab lists the app's users: everyone who signed up through the branded page or was bound to the app as their home app.
For each user the table shows their status (Active, Waiting for approval or Archived), when they last signed in, when they were last active in the app, and when they signed up. Search by name or email, filter by status, choose the page size and sort by user or sign-up date. Sessions and time spent in the app are on the Analytics tab, where the users table is paged and searchable in the same way.
Actions on each user:
| Action | Effect |
|---|---|
| Activate | A waiting account becomes usable (shown for accounts waiting for approval). |
| Deactivate | The account can no longer sign in, and any current session ends. The account and its data are kept; activate it again at any time. |
| Email a password reset link | Sends the user a link to the app's branded reset page. |
| Remove from the app | The user is signed out and loses access to this app; the app is no longer their home app. Their platform account is kept. |
Signing out
A home app fills the whole screen with no Strongly controls, so the app provides its own sign-out. There are two ways; both end the user's session and show the app's sign-in page.
A link in the app. The app proxy answers _strongly/sign-out under the app's own address. From inside the app, link to it relative to the app's root with target="_top", so the navigation replaces the whole page rather than the frame the app runs in:
<a href="_strongly/sign-out" target="_top">Sign out</a>
If your app is served under a path prefix, the address is <X-Forwarded-Prefix>/_strongly/sign-out, for example /api/proxy/<app-id>/_strongly/sign-out (see User Identity Headers).
From script. A fetch of the same address ends the session and answers JSON with where to send the browser next:
const res = await fetch('_strongly/sign-out', { method: 'POST' });
const { redirect } = await res.json(); // "/<url-name>/" (or "/login" when the app has no branded sign-in)
window.top.location.href = redirect;
The sign-out page. https://<your-platform>/<url-name>/sign-out (in the Pages list) does the same from a plain link, so it also works from an email or a bookmark.
Either way the user lands on the app's sign-in page. For an app without branded sign-in, the same _strongly/sign-out address signs the user out and shows the platform sign-in page.
Charging for access
An app with branded sign-in can charge its users with your own Stripe account: single-user plans, team plans with seats, or both. The setup, what users see and how subscriptions are managed are on their own page: Charging for Access.