A reset belongs where the sign-in is, even for somebody Rutba has never met
From 26 September, staff reset their password at Rutba’s sign-in and a shop’s customers reset at the shop, never across. Somebody only their company’s workspace knows can now reset at Rutba too, and every address still gets the same answer.
· 7 min read
A password reset looks like the simplest page on any site: an address, a button, a mail. It stops being simple when one company’s software holds two kinds of people. A company running a Rutba workspace has the people who work in it — at the till, in the stock room, on the books — and, if it runs a shop, the people who buy from it. Both have an address and a password, and the first thing a reset page has to know is which of them it is for.
The rule, settled on 25 September, is short: a reset belongs where the sign-in is. Since one sign-in reached every workspace, the people who work in a workspace sign in at Rutba’s sign-in, auth.rutba.io, so that is where they reset. A shop’s customers sign in at the shop, so they reset at the shop. Nobody resets across. From 26 September every reset works that way, and this is what it means for you.
Two kinds of account, two doors
A company’s workspace keeps its staff and its shop’s customers side by side, and each door now looks only for its own kind:
| If you | You sign in and reset at | The other door |
|---|---|---|
| Work in a company’s workspace | Rutba’s sign-in | The shop’s reset never touches your account |
| Buy from a company’s shop | The shop | Rutba’s reset never touches your account |
| Do both, with one address | Each, for its own account | Two accounts, two passwords; neither reset reaches the other |
So a member of staff who types their address into the shop’s password reset page gets no mail, and a customer who asks Rutba’s sign-in gets none either. Neither is a fault: the right door is the one that holds that password. A shop’s reset link comes back to the shop. Even a workspace’s break-glass sign-in, kept for reaching it without Rutba, resets staff only, and its link comes back to that form, never to the shop.
Somebody Rutba has never met
One sign-in left one person without an obvious way in. A company can set somebody up in its own workspace — a new cashier, a bookkeeper, a manager — without that person ever making a Rutba account. Once the workspace signed in through Rutba, they had a workspace password and no Rutba account to sign in with. If they asked Rutba’s sign-in for a reset, they were told to check their email, and nothing came, because there was no Rutba account to send it for.
That reset now works. Ask for one at Rutba’s sign-in with the address your workspace has for you, and this is what happens:
- The page answers as it does for everybody: check your email.
- Then, with the answer already given, Rutba asks the live workspaces it runs whether the address belongs to one of their staff. Each answers yes or no, and records that it was asked, naming the address only by a fingerprint of it. A demo or staging workspace is never asked.
- If one says yes, a mail arrives: “Set your Rutba password”, naming the workspace. The link works once and lasts an hour. If none says yes, nothing is sent.
- The link asks for your name and a password, and nothing else. Setting them makes your Rutba account, already confirmed, since opening the link proved the mailbox. It also makes you a member, with the lowest role, of the company’s organisation wherever a workspace said yes.
- Then sign in. The workspace is on your list and opens straight in, as you. It takes the same password too, so there is one password rather than two.
Two things stay where they were. What you may do inside the workspace is still granted there, by whoever runs it: the reset connects your Rutba account to the record the workspace already had and changes none of its permissions. And only the workspaces that said yes are connected. If the company runs another workspace that has never heard of you, it is not told about you on your behalf.
The same answer for every address
The dead end had a reason, and the reason had to survive the fix. A reset page that says “no account with that address” is a free way to find out who works where: type in a list of names at a company and keep the ones it recognises. That is why Rutba’s reset has always said the same thing to every address — and why somebody nobody had set up at Rutba was told to wait for a mail that was never coming.
So the new path runs after the answer, not before it. The page, its words and the time it takes are the same for an address with a Rutba account, an address only a workspace knows, a shop’s customer and an address that belongs to nobody: “If that address belongs to a Rutba account, a link to set a new password is on its way.” The difference is in the mailbox, which only its owner can open. The shop’s reset and the workspace’s break-glass reset answer the same way, account or not. It is the rule the lookup before your password already keeps, applied to the reset.
Only the mailbox can tell an address with an account from one without. The page never does.
The organisation you last chose, kept
Somebody who works for more than one organisation — their own, and a client whose books they keep — picks one, and every app follows it until they switch. That choice used to live on the sign-in, so it went when the sign-in did: once every sign-in you had was over, because you signed out, reset your password or simply stayed away long enough, the next one could ask you again.
It is now kept on your account as well. Your next sign-in opens in the organisation you last chose, in every app, for as long as you are still an active member of it and it is neither suspended nor closed. If you have left it, or it has closed, nothing is carried over and you choose as you did the first time.
A workspace on your own domain keeps up
Most workspaces live at an address under rutba.io, where a small hidden page asks Rutba’s sign-in who is signed in, and as which organisation, while you work. A workspace can also live at a company’s own address, and there the hidden page cannot work: a browser does not send Rutba’s sign-in cookie to a page embedded in a site on another domain, and the setting that would allow it depends on third-party cookies, which more and more browsers block.
So on those workspaces the app does the check in the open. When a page loads, or when you come back to its tab, it goes to the workspace’s sign-in in the whole window — “Checking your sign-in”, for a moment — and comes back to the same page at the same address. It does this at most once every five minutes per app, and never while you are part-way through a form, because the reload would lose what you had typed. Still signed in at Rutba, you never see a sign-in page. Switched organisation at Rutba, the page comes back in the one you chose. Signed out at Rutba, you land on the sign-in.
What it cannot do is reach a page nobody is looking at. A tab left open on a desk learns about a sign-out when it is next loaded or looked at, not before.
Signing out ends all of it
While you work, a workspace quietly renews its sign-in in the background, for every tab and every app that shares it. When you sign out of the workspace, all of that ends together: every renewal, in every tab, including a tab left idle long enough that its own short-lived pass had run out. Nothing that sign-in was given works afterwards.
It is the sign-in in this browser that ends. The one on your phone is a separate sign-in, and it stays until you sign out there.
Never set a Rutba password?
Ask Rutba’s sign-in for a reset with the address your workspace knows, and set one from the mail.
Reset at Rutba’s sign-in
