Features
Signing in
How sign-in works for residents, managers, board members and Vara staff, how long a link and a session last, and what each refusal on the sign-in page actually means.
One section of this article carries operator-only instructions. They are published so the whole picture is visible, and nobody outside Vara can act on them. They are marked where they appear: Operator notes on the degraded modes.
You type your email address on the sign-in page. If the service recognises it, you get an email with a link. Opening that link signs you in. There is no password to remember and none to lose.
- 1Open the sign-in pageOperatorManagerBoardResident
The page shows only what is actually working. If the bot check or the email delivery is not configured, you get a notice explaining that instead of a form that would fail when you pressed it.
- 2Ask for a linkOperatorManagerBoardResident
Enter the email address the association has on file for you. The page does not tell you whether the address is known, on purpose: an answer either way would let anybody test whether a neighbour has an account.
- 3Open the link within 15 minutesOperatorManagerBoardResident
The link lasts 15 minutes and works once. Opening it a second time will not sign you in again, and neither will forwarding it to somebody else. Ask for a fresh one instead.
- 4Work for up to 8 hoursOperatorManagerBoardResident
A session lasts 8 hours. After that you sign in again the same way. Signing out ends the session immediately.
The sign-in page carries a "Vara staff: sign in with Google" link when Google sign-in is configured for the deployment. When it is not configured the link is absent rather than present and broken, which is the difference between a service that is missing a capability and one that appears to have it.
It is a route, not a role
Signing in with Google gets you a session. What you can then do is decided by the role your account carries, exactly as it is for a link sign-in. Arriving through Google does not make anybody an operator.
| Limit | Value | What it means for you |
|---|---|---|
| Sign-in link lifetime | 15 minutes | Ask for a new one rather than hunting for the old email. |
| Sign-in link uses | One | A link that has been opened will not open again, including on another device. |
| Link requests | 5 per address per hour | Counted across the whole service, not per browser or per server. The sixth request in an hour is refused. |
| Session length | 8 hours | Long enough for a working day. It does not extend as you use it. |
Registering shares the same budget
A registration that is approved automatically also sends a sign-in message, and it draws on the same five requests per hour. If you have just registered and then asked for several links, you can run out. Wait for the hour to turn rather than trying again.
| What you see | What is actually happening | What to do |
|---|---|---|
| A notice where the form should be | The bot check or the email delivery is not configured on this deployment, so no link could be sent. | Contact the management office. This is a setup state, not something you can work around. |
| A service error naming a session secret | The service is running without its session key. No session can be created and none will be accepted. | Report it. Every signed-in page is refusing, for everybody, until an operator fixes it. |
| The link says it has expired or been used | More than 15 minutes passed, or the link had already been opened. | Ask for a new link. |
| You are signed in but every page refuses | Your account exists and its role is not one the page admits, or the registration is still pending. | Read Who can do what. If your registration is pending, a manager has to approve it before anything opens. |
| Too many requests | Five link requests for that address in the last hour. | Wait. The limit is global, so trying from another device will not help. |
Operator notes on the degraded modes
Operator onlyThis section is for Vara operators
It describes deployment states and the startup log. Nobody outside Vara can act on it.
The service boots and serves its public landing page even when authentication is unconfigured, rather than refusing to start. That choice is deliberate: taking down the front door because an unrelated capability is missing trades something working for nothing. The cost is that "signed in and working" and "authentication unconfigured" have to be told apart from outside, so each degraded mode is published on the health endpoint and written to the startup log at boot.
- No session secret: every authenticating route refuses. No per-process key is generated, because three instances with three keys would sign people out at random and say nothing.
- Turnstile unconfigured: the link request route refuses rather than accepting unverified requests.
- Link delivery unconfigured: the link request route refuses rather than issuing a link nobody sends.
- Google unconfigured: the staff button is not rendered and the route refuses. Mounting the client secret is an operator action, not a code change.
Still stuck?
That is a fair place to be, and it is usually faster to ask than to keep reading. Your association's management office can tell you whether what you are hitting is a permission, a setup step or a fault. Say what you were trying to do and what the screen said. If it needs changing at the service level, they will bring Vara in.