Access

Access puts a gate in front of a path of your site, such as /admin*, a staging site or a preview, without any change to the app. The gate asks for one of two things:

• A password you share with whoever needs to get in.
• An e-mail address on your list. The visitor types it and gets a sign-in link that works once, for 15 minutes.

Whoever gets in receives a signed cookie and browses for the session length you set. With the e-mail link, your app receives the e-mail of the person who entered in a header, so it knows who is there. The gate holds in observe mode too, since it is a lock you set and not a guess, so a staging site stays private from day one.

Access is part of the Pro plan.

Turn it on

It runs in the connector: the Qlyne proxy, the hosted connector or the Cloudflare Worker. With the connector installed:

1. In the dashboard, open your site and go to Access, Configuration.
2. Click Add gate. Give it a name, pick how people get in, add the routes, then the e-mails or the password, and the session length.
3. Done closes the window. Save the page: the gate applies only after that, and the connector picks it up within a minute.
4. Open one of the routes in a private window. You should see the “Restricted access” page.

With the proxy or hosted, every request goes through the connector, so any path can be gated. On Cloudflare, the Worker’s routes must cover the gate’s paths. The limit on password tries uses Cloudflare’s rate limiting, which needs the connector deployed with Wrangler and the wrangler.toml from the dashboard (see Install the connector). With the dashboard install the gate works, but tries are not limited.

Settings

Each gate has:

• Name: shows in the dashboard and in the sign-in e-mail. Each name is used once per site.
• How people get in: Link by e-mail or Password.
• Routes: the paths the gate locks, starting with /. * matches the rest, so /admin* covers /admin, /admin/ and everything under it, images and scripts included. /* locks the whole site. Up to 50 routes per gate.
• Who can enter (link by e-mail): addresses, or @yourcompany.com for everyone with an address there. Up to 200 per gate.
• Password: at least 8 characters. Qlyne stores only a hash of it, so nobody can read it back. The field shows “Set, type to change it” once a password exists; leave it empty to keep the current one.
• Stay signed in for: 1 hour, 12 hours (the default), 1 day or 1 week.

A site can have up to 10 gates. Each gate has its own session: entering /staging does not open /admin. If two gates cover the same path, the first one in the list applies.

Access has no protection levels: what to lock is a choice about your site, not a strength. Gates are also part of rules as code and of the MCP server, and neither ever returns the password.

What your app receives

A visitor who came in by e-mail link reaches your app with the header Qlyne-Gate-User and their e-mail, even with the other signals turned off. A password gate sends no e-mail, since everyone shares the same password. The connector removes any Qlyne-* header the visitor sends, so the value can’t be forged.

// Node
const who = req.headers['qlyne-gate-user'] || null;

// Laravel
$who = $request->header('Qlyne-Gate-User');

What visitors see

• A browser without a session: 401 with the “Restricted access” page. A password gate shows “Enter the password to continue.” and an Enter button. An e-mail gate shows “Enter your e-mail to get an access link.” and a Send link button.
• After asking for a link: “Check your e-mail”. The page says the same to everyone, on the list or not, so it never tells who has access. The e-mail arrives with the subject “Access link: ” and your site’s address, and a Sign in button.
• The right password or a valid link: the visitor lands on the page they asked for, inside the session.
• A wrong password: the same page with “Wrong password.” More than 10 tries in a minute from one IP get 429 and “Too many tries. Wait a minute and try again.”
• A link already used, or older than 15 minutes: “Link expired”, with a prompt to ask for a new one.
• An API call or a script without a session: 401 with {"code": "GATE_REQUIRED"}.
• A trusted IP address from IP lists skips the gate along with every other rule.

The gate pages follow the visitor’s browser language, English or Portuguese.

Limits

• The sign-in e-mail goes out in English for now, whatever the visitor’s language.
• Changing the password or removing an address from the list does not sign out who is already in. Their session lasts until it expires. Renaming the gate signs everyone out of it at once.
• The session has a fixed length, counted from the moment the person entered. There is no sign-out for inactivity.
• The gate has no two-factor sign-in and no single sign-on. There is no gate by IP address; trust the address under IP lists instead.
• The Access Reports count how many people were asked to sign in and how many entered, without who entered. The e-mail goes only to your app, in Qlyne-Gate-User.
• Password tries are counted per IP. With more than one proxy, each one counts its own share.

FAQ

Does it replace my admin’s login?

No. Keep your app’s login. The gate stands in front of it: whoever lacks the password or isn’t on the list never reaches your login page, so bots can’t try passwords on it. With the e-mail link, your app can also read Qlyne-Gate-User to know who passed the gate.

What about the whole team?

Use a gate by e-mail link with @yourcompany.com in Who can enter: everyone with an address there gets in with their own link, and your app sees who each one is. Add outside people one address at a time, up to 200 per gate. A shared password works too, but when someone leaves you have to change it and rename the gate to sign everyone out.

Can I let my own IP in?

Yes, through the firewall. Add your address as trusted under IP lists: it skips the gate and every other rule, the challenge and the rate limits included. Use it for your office or an uptime monitor. Everyone else still meets the gate.

Does the session work in every browser?

No. The session lives in a cookie in the browser where you entered. Another browser, your phone or a private window asks again. The cookie is not tied to your IP, so changing networks keeps you in until the session ends.

Is it on Free?

No, Access is part of Pro. Every new account gets 7 days of Pro, no card. On Free, the gates stay saved in the dashboard, but the connector doesn’t apply them, so the paths they locked are open to everyone. If a site goes back to Free, check what was behind a gate. See Plans.

Troubleshooting

The sign-in e-mail does not arrive

The page says “Check your e-mail” to everyone, so check the list first:

• The address is on Who can enter exactly as typed, or its domain is there with @.
• The page was saved after Done, and the site is on Pro.
• One address gets up to 5 links in 15 minutes. Further requests send no e-mail; wait and ask again.
• The e-mail comes from Qlyne, in English, with the subject “Access link: ” and your site’s address. Look in the spam folder.

I enter and get asked again

The browser is not keeping the gate’s cookie. Three causes, from the most common:

• The site is served over plain HTTP. The cookie is only kept over HTTPS. Serve the site over HTTPS.
• The proxy sits behind your web server, which does not send X-Forwarded-Proto. The sign-in link then starts with http://. Add the header as in the proxy guide.
• The browser blocks cookies for your site. Allow them, or try another browser.

Renaming a gate or changing the connector secret also asks everyone to sign in once more.

My API stopped working behind the gate

Calls without a session get 401 with {"code": "GATE_REQUIRED"}, and the form only works in a browser. A page inside the gate that calls its own API with fetch sends the cookie, so it keeps working. For other callers, such as a mobile app, a webhook or a server:

• List in Routes only the paths to lock, and leave the API out. A gate on /* covers every path.
• Or trust the caller’s IP under IP lists.