Auto-Login
Auto-login lets you identify a user who’s already logged into your product, then carry that identity into FeedbackJar:
- Widget — attribute their posts to a portal profile
- Portal — open the public board already signed in (
navigateToPortal()), without a separate login screen
It is separate from Single Sign-On, which is for someone who lands on your board and clicks Log in.
Enable auto-login
- Open Settings → Auto-login in your project dashboard.
- Toggle Enable auto-login on.
- Copy your secret key and organization ID.
Keep the secret on your server only.
How it works
- After a user logs into your app, your backend creates an HMAC-SHA256 signature over
userId:email:timestampusing your project secret. - Your frontend calls
window.fj.identify(...)with the user fields plussignature,timestamp, andorganizationId. - Widget submissions and portal handoff use that signed identity so FeedbackJar can verify it came from your backend.
What happens after identify()
Once the SDK has a fresh signed identity, FeedbackJar can attach authentication data to portal links on your page.
Links that point at your FeedbackJar board (your *.feedbackjar.com subdomain or a verified custom domain) get a short-lived fj_auth query param automatically — including links you already rendered in your product UI. Opening them lands the user signed in, without a second login.
You can still build URLs explicitly with getPortalUrl() / navigateToPortal() when you prefer SDK-controlled navigation.
Clear identity on logout with window.fj.identify(null) — enriched links are restored to their original hrefs.
How long a signature lasts
| Use | Max age |
|---|---|
Opening the portal (navigateToPortal) | 15 minutes — re-sign if needed before opening the board |
| Submitting feedback from the widget | 7 days — fine to identify once per app session |
Generate timestamp on the server when you sign. The client must send that exact value back — don’t replace it with a new Date.now() in the browser.
Signing the token
const crypto = require('crypto');
const secretKey = 'YOUR_SECRET_KEY';
const userId = 'user_123';
const email = 'user@example.com';
const timestamp = Date.now();
const signature = crypto
.createHmac('sha256', secretKey)
.update(`${userId}:${email}:${timestamp}`)
.digest('hex');
// Return signature, timestamp, userId, and email to the client unchanged. Node.js, Python, PHP, Ruby, and C# examples (pre-filled with your project’s secret) are in Settings → Auto-login.
Identifying the user (web)
<script src="https://cdn.feedbackjar.com/sdk.js"></script>
<script>
window.fj.init('YOUR_WIDGET_ID');
</script> // After login, fetch the signed payload from your backend
window.fj.identify({
id: 'user_123',
email: 'user@example.com',
firstName: 'John',
lastName: 'Doe',
avatar: 'https://example.com/avatar.jpg',
organizationId: 'YOUR_ORGANIZATION_ID',
signature: 'GENERATED_ON_SERVER_SIDE',
timestamp: 1234567890123 // same value used to sign
});
// Optional: open the feedback portal already signed in
window.fj.navigateToPortal();
// Or with a custom domain:
window.fj.navigateToPortal('feedback.yourdomain.com'); Without signature, timestamp, and organizationId, identify only personalizes the widget. See User Identification.
Automatic link enrichment
After a signed identify(), the widget SDK watches the host page and appends fj_auth to FeedbackJar portal links it can verify:
- Your project’s public portal URL (from widget config)
{slug}.feedbackjar.com- Verified custom domains
Dynamically added links (SPA route changes, late-rendered nav) are picked up as well. Identity older than 15 minutes is not attached — re-sign and call identify() again before opening the board.
<!-- Before identify(): plain portal link -->
<a href="https://acme.feedbackjar.com/roadmap">Roadmap</a>
<!-- After signed identify(): same anchor carries the session -->
<a href="https://acme.feedbackjar.com/roadmap?fj_auth=...">Roadmap</a> Auth is never attached to unrelated domains.
Identifying the user (iOS / Android)
On mobile, build the same payload, base64url-encode it, and append it as the fj_auth query parameter when opening the portal URL. Samples in Settings → Auto-login match this shape.
Payload reference
| Field | Required | Description |
|---|---|---|
id | Yes | Stable user ID from your system |
email | Yes | User’s email — included in the signature |
timestamp | Yes | Unix ms used when signing |
signature | Yes | HMAC-SHA256 of userId:email:timestamp, hex-encoded |
organizationId | Yes | Your FeedbackJar project ID |
firstName | No | Profile field |
lastName | No | Profile field |
avatar | No | Avatar URL |
Security notes
- Never expose your secret key in client-side code.
- Rotate the secret if it’s ever leaked — old signatures stop working immediately.
- Project owners and admins should manage the board from the FeedbackJar dashboard; auto-login is meant for your end users.
- Automatic link enrichment only attaches
fj_authto your verified portal hostname(s) — never to arbitrary third-party links.
Troubleshooting
| Error / symptom | What to check |
|---|---|
| Name shows in the widget but there’s no portal profile / empty “My requests” | Signature fields missing — sign on your backend and pass them to identify |
Organization not found | Wrong organizationId |
Auto-login is not enabled for this organization | Turn it on in Settings → Auto-login |
Secret key not configured | Generate a secret in Settings → Auto-login |
Token expired or invalid | More than 15 minutes since timestamp for portal handoff — sign again |
Invalid signature | Message must be userId:email:timestamp with the current secret; email and timestamp must match exactly |
Auto-login vs. Single Sign-On
| Auto-login | Single Sign-On | |
|---|---|---|
| Who starts it | Your app, via the widget SDK | The user, by clicking “Log in” on your public board |
| Best for | Logged-in users inside your product | Visitors who land on the board directly |
| Format | HMAC-SHA256 in identify / portal URL | JWT (HS256) via a redirect to your server |
| Public redirect endpoint on your server | No | Yes |