Authentication · sessions
The login works and then immediately does not
You sign in, the dashboard flashes, and you are back at the login screen. Or everything is fine until someone refreshes. Or the magic link opens and nothing happens. These look like three bugs; they are usually one, in the handful of lines that decide where the session is kept and who is allowed to receive it.
Bring the exact symptom and whether it happens in an incognito window — that alone narrows it to one of four causes.
- First step
- A short call, or a written description if you would rather not talk yet
- Who you speak to
- The engineer who would do the work. No account manager, no sales call.
- Turnaround
- Most single problems are resolved within 48 hours of getting access
- Cost
- Quoted after we have seen it — scope varies, and guessing helps neither of us
How to get this fixed
Already a client? Raise it as a ticket in Golux Club and it enters the queue with an SLA attached.
The four things this ever is
First: the redirect URL the app sends is not in Supabase's allow-list, so the session never comes back — this is the one that appears the day you move to a custom domain. Second: the OAuth or magic-link flow returns a code the app never exchanges, because the handler that should do it runs on the wrong route or after a redirect has already happened. Third: the session is held in memory rather than in storage that survives a reload, so the first refresh empties it. Fourth: something checks 'is the user logged in' before the client has finished reading the stored session, decides no, and redirects — the loop is your own guard racing your own auth library.
How to tell it is this
- It works in development and fails on the deployed domain — that is the allow-list
- The URL briefly contains `?code=` or `#access_token=` and then the app forgets
- A hard refresh logs you out but opening a new tab does not, or the reverse
- The redirect happens so fast the dashboard only flickers — that is the guard racing hydration
- Magic links work in the browser that requested them and nowhere else
What we do
Diagnosis is most of it. The change is usually small.
- 01
Watch one real sign-in
The whole round trip: what the app asks for, what comes back, what is stored, what reads it. The failure is visible in that trace every time.
- 02
Fix the cause, not the symptom
Allow-listed redirect URLs for every environment, the code exchange on the route that actually receives it, session storage that survives a reload.
- 03
Make the guard wait
The route protection stops deciding before the session is known — which is what turns a redirect into a loop.
- 04
Check the flows nobody tests
Password reset, magic link opened in a different browser, sign-out on one tab with another tab open, and the token refresh an hour later.
What you get
- Sign-in, refresh, sign-out and token refresh working on every environment you have
- The redirect allow-list written down, so the next domain change does not break it
- Password reset and magic link checked, not assumed
- A note on what was actually wrong — it is worth knowing
When this is not what you need
- You want to add a new sign-in method (Google, SSO, phone) — that is a feature, quote it separately
- Users can sign in but see the wrong data — that is row-level security, a different page
- You need roles and permissions designed from scratch — that is architecture work, not a fix
How it works
- 01
Tell us the symptom
One paragraph is enough — the error, the screen, what you expected. Run the free audit first if you have not; it often names the problem for you.
- 02
A call, or a written reply
Thirty minutes to look at it together, or a written answer if you prefer. Either way you find out what it is before anything is agreed.
- 03
A written offer
After the call: the scope, the approach and what we need from you. Discussed on the call, confirmed in writing.
- 04
Fixed, explained, handed back
The fix in your project, a short note on what was wrong and why, and how to check it yourself — typically inside 48 hours of getting access.
What we promise before any money changes hands
We tell you what is actually wrong, whether it is one problem or a symptom of a bigger one, and what it would take — before you commit to anything. If the honest answer is that you can fix it yourself in an afternoon, that is the answer you get, and the instructions are usually on this page already.
Questions
- It works for me and fails for some users. Same problem?
- Often yes — third-party cookie behaviour and private browsing change where a session can be stored, so a setup that works on your machine fails on someone's locked-down browser. We test in a private window as a matter of course.
- I turned off email confirmation to test and now it is worse.
- That is a common detour: with confirmation off, accounts exist in a different state than they will in production, so you end up fixing the wrong thing. We test with the settings you intend to ship.
- Could this be why my magic links expire instantly?
- Usually the link is being consumed by a preview fetcher — a mail client or a security scanner opening the URL before the human does. The fix is the same flow work, plus a token type that survives it.
- Does this cover both web and mobile?
- The diagnosis carries across — if a web app and a React Native app have the same problem, the second is usually quick. Mention both on the call and the offer covers them honestly rather than twice.
Other things we fix at the same price
- Login works, no data shows“I can log in, but every list is empty and there is no error.”
- Move it to my own domain“My app is still on yourapp.lovable.app and I want my own domain.”
- The build or deploy is failing“The deploy fails, or it works in preview and breaks in production.”
Next step
Tell us the symptom. We will tell you if it is one problem.
We answer within a few hours with what it is, what it would take, and what we need from you. If it is bigger than one problem, we say that instead — before anything is agreed.
