Question about sharing links potential improvement

[fuzoh]

Hi,
First, amazing tool, thanks !

I have some questions for potential improvements.

Two findings :

1. When using the sharing link of a document, there is no way to obtain a link that automatically redirect the user to login before viewing the document. So actually most user stay stuck on the document validation page not showing the document (see capture), and do not understand that they need to login first.

2. This problem does not exists with the link sent by email. With the mail, the link works, but only with magic link authentication.

My questions:

• Would-it-be possible to add a more "intelligent" link, that redirect to the login, then goes back to the document validation page ? to avoid the user confusion.
• When using oauth login, is it possible to have the emailed links work also with oauth ? to avoid the "magic link not activated" error.

I haven't investigated the code or prepared POC for now.

Look for discussion, thanks

[btouchard]

Hello @fuzoh
Yes, I understand the issue, and I think it’s my mistake.
You’ve enabled SMTP, but you haven’t explicitly set MAGIC_LINK in the environment variables, have you?
The admin panel is therefore allowing you to send the reminder, but the link isn’t authenticating.
I’ll fix this by improving the user experience on this page so that users can log in directly from the login page.
Thank you for your feedback

[fuzoh]

Hi,

Exactly, during the first attempt I set up OAuth and SMTP, using only ACKIFY_AUTH_OAUTH_ENABLED=true. Then I tried with both ACKIFY_AUTH_OAUTH_ENABLED=true and ACKIFY_AUTH_MAGICLINK_ENABLED=true. These two provokes the behaviour exposed in the issue.

If I set the ACKIFY_AUTH_MAGICLINK_ENABLED=false, then, I get a 503 {"error":{"code":"SERVICE_UNAVAILABLE","message":"Magic Link not enabled"}}. (when clicking on the link in the reminder email).

Feel free to ask if more details needed

Thanks

[btouchard]

Thanks for the precision @fuzoh — that matches what I traced. The 503 you see with ACKIFY_AUTH_MAGICLINK_ENABLED=false is exactly the path that gets fixed: HandleVerifyReminderAuthLink was gated on IsMagicLinkEnabled(),
so OAuth-only deployments rejected reminder links even though the underlying token was valid.

Just to make the new behaviour explicit across your three setups:

• OAUTH_ENABLED=true only / MAGICLINK_ENABLED=false: reminder link clicks now log the recipient in via the reminder-auth session (independent from OAuth) and redirect them to /?doc=<id>. No 503.
• Both OAUTH_ENABLED=true and MAGICLINK_ENABLED=true: same as before, plus the shared-link confusion is now mitigated by the new login banner / "Sign in to confirm" CTA.
• Worth noting: a recipient who authenticates via the reminder link gets a session with sub = "reminder:<email>", distinct from their OAuth sub if they later log in through the OAuth provider. The signature is recorded
  under whichever sub was active at sign time. That's by design — the reminder is meant to give the recipient a frictionless one-click path to sign without forcing them through your IdP.

different scope from this issue.

Patches are on main (commits fac7c23 + c04d8be), will go out in the next release.